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ABSTRACT 

The  objective  of  the  ASCACT  (Advanced  Shipboard  Command  and  Control 
Technology)  project  is  to  improve  data  processing  capability  for  shipboard  Command  and 
Control  Information  Systems  (CCISs)  by  developing  a  multiprocessor  testbed.  The  general 
purpose  of  the  ASCACT  testbed  is  for  the  integration  of  high  performance  Commercial 
Off-The-Shelf  (COTS)  products  into  the  shipboard  CCIS  in  order  to  resolve  the  envisioned 
high  speed,  high  throughout,  data  base  intensive  applications  of  the  future.  The  ASCACT 
testbed  will  allow  investigations  to  occur  on  any  combination  of  these  requirements.  To 
fulfill  the  objective  of  an  ongoing  task  sponsored  by  the  Directorate  Maritime  Ship  Support 
(DMSS  8),  the  Defence  Research  Establishment  Valcartier  (DREV)  is  currently  providing 
consulting  services  in  support  of  the  ASCACT  project.  The  content  of  this  document 
responds  to  the  requirements  of  Activity  1  of  the  task.  In  that  respect,  the  document 
identifies  and  describes  the  R&D  work  conducted  at  DREV  in  the  areas  of  Multi-Sensor 
Data  Fusion  (MSDF),  Situation  and  Threat  Assessment  (STA)  and  Resource  Management 
(RM)  that  can  potentially  be  used  in  the  ASCACT  testbed.  It  also  discusses  the  level  of 
effort  to  port  that  technology  to  ASCACT.  In  addition,  an  overview  of  the  ASCACT 
project,  a  discussion  of  the  context  in  which  the  project  is  conducted,  and  a  description  of 
the  ASCACT  Integration  Working  Group  mandate  and  activities  are  also  presented. 


RESUME 

L'objectif  du  projet  TACECN  (Technologie  avancee  du  commandement  et  controle 
naval)  est  d'ameliorer  la  capacity  de  traitement  des  donnees  pour  les  systemes  d'information 
du  commandement  et  contrdle  (SICC)  navals  par  le  diveloppement  d'un  banc  d'essais 
multiprocesseurs.  Le  but  giniral  du  banc  d'essais  TACECN  est  l'integration  de  produits 
commerciaux  haute  performance  dans  le  SICC  naval  de  fagon  h  resoudre  les  besoins 
anticipes  des  futures  applications  impliquant  de  grandes  vitesses  de  calcul,  de  nombreux 
transferts  de  donnies,  et  a  forte  intensity  en  requites  pour  les  bases  de  donnees.  Le  banc 
d'essais  TACECN  permettra  de  faire  des  recherches  sur  toute  combinaison  de  ces  besoins. 
Pour  realiser  l'objectif  d'une  tache  courante  parrainee  par  le  Directeur  -  soutien  aux  navires 
(DSN  8),  le  Centre  de  recherches  pour  la  defense,  Valcartier  (CRDV)  foumi  presentement 
des  services  consultatifs  pour  appuyer  le  projet  TACECN.  Le  contenu  de  ce  document 
repond  aux  besoins  de  l'activite  1  de  la  tache.  En  ce  sens,  le  document  identifie  et  decrit  le 
travail  de  R&D  mend:  au  CRDV  dans  les  domaines  de  la  fusion  de  donnees  provenant  de 
capteurs  multiples  (FDCM),  de  1'evaluation  de  la  situation  et  de  la  menace  (ESM)  et  de  la 
gestion  des  resources  (GR)  et  qui  pourrait  potentiellement  etre  utilise  dans  le  banc  d'essais 
TACECN.  Le  niveau  d'effort  pour  transferer  cette  technologie  a  TACECN  est  aussi 
discute.  De  plus,  un  survol  du  projet  TACECN,  une  discussion  du  contexte  dans  lequel  le 
projet  est  meni,  et  une  description  du  mandat  et  des  activities  du  groupe  de  travail  sur 
l'integration  dans  TACECN  sont  aussi  presentes. 
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EXECUTIVE  SUMMARY 

It  is  anticipated  that  the  principal  threat  to  our  surface  ships  in  the  open  ocean  and 
littoral  operating  scenarios  of  the  future  will  be  from  air  attacks  by  sophisticated,  fast  anti¬ 
ship  missiles  fired  from  air,  surface,  subsurface  or  shore-based  platforms,  at  closely 
spaced  arrival  intervals,  and  by  aircraft  dropping  guided  or  unguided  bombs.  These  air 
attacks  are  characterized  by  great  rapidity  (imposing  very  short  reaction  time),  lethality  and 
multiple  simultaneous  engagements  in  a  very  complex  environment. 

The  approach  put  forward  and  developed  by  the  Data  Fusion  and  Resource 
Management  (DFRM)  Group  at  the  Defence  Research  Establishment  Valcartier  (DREV)  to 
help  counter  this  threat  is  to  increase  the  Above  Water  Warfare  (AWW)  defence  capability 
of  Canadian  Patrol  Frigates  (CPFs)  through  the  development  of  a  real-time,  semi- 
automated  advisory  decision  support  system.  Such  a  system  must  continuously  take  in  data 
from  the  ship’s  sensors  and  other  information  sources,  build  an  accurate  AWW  tactical 
picture  as  quickly  as  possible,  provide  the  most  likely  interpretation  of  the  tactical  situation, 
suggest  options  to  defend  the  ship  using  the  best  possible  combination  of  hardkill/softkill 
weapons  or  other  defensive  means  (e.g.,  suggest  an  optimal  sequence  of  sensor  and 
weapon  allocations)  and  present  fused  information  and  decision  support  analysis  results 
with  the  opportunity  for  the  Commanding  Officer  and  AWW  team  to  accept/reject 
recommended  actions/plans  in  a  timely  manner,  and  coordinate  and  direct  execution  of 
these  actions/plans. 

Such  future  naval  systems,  built  using  a  combination  of  numerical  and  artificial 
intelligence  technologies,  will  have  severe  data  and  information  processing  requirements 
placed  upon  them.  Warships  will  also  have  a  requirement  for  a  rapid  and  simple 
communication  medium  for  the  integration  of  combat  system  computers.  The  Advanced 
Shipboard  Command  and  Control  Technology  (ASCACT)  project,  also  known  as  project 
D6195,  has  been  setup  and  approved  in  1987  with  the  objective  to  improve  shipboard  data 
processing  capability  for  Command  and  Control  Information  Systems  (CCIS)  by 
developing  an  Advanced  Development  Model  (ADM)  multiprocessor  testbed.  The  general 
purpose  of  the  ASCACT  testbed  is  for  the  integration  of  high  speed  Commercial  Off-The- 
Shelf  (COTS)  products  into  the  shipboard  CCIS  in  order  to  resolve  the  envisioned  high 
speed,  high  throughout,  data  base  intensive  applications  of  the  future.  The  ASCACT 
testbed  will  allow  investigations  to  occur  on  any  combination  of  these  requirements. 

Project  D6195  is  managed  by  the  Directorate  Maritime  Ship  Support  (DMSS  8). 
The  ASCACT  Integration  Working  Group  (AIWG)  has  been  established  by  both  DMSS  8 
and  DREV  to  fulfill  a  jointly  identified  requirement  for  a  formal  information  exchange 
mechanism  between  the  two  organizations  about  R&D  issues  relevant  to  ASCACT. 
Through  a  task  entitled  "Capture  of  the  ASCACT  Integration  Testbed  Requirements"  and 
an  active  participation  in  the  AIWG,  the  DFRM  group  is  currently  providing  consulting 
services  in  support  of  the  preparation  for  the  Integration  Phase.  The  content  of  this 
document  responds  to  the  requirements  of  Activity  1  of  the  task.  In  that  respect,  it  identifies 
and  describes  the  R&D  work  conducted  at  DREV  in  the  areas  of  shipboard  Multi-Sensor 
Data  Fusion  (MSDF),  Situation  and  Threat  Assessment  (STA)  and  Resource  Management 
(RM)  that  can  potentially  be  used  in  the  ASCACT  testbed  and  it  discusses  the  level  of  effort 
to  port  that  technology  to  ASCACT.  In  addition,  an  overview  of  the  ASCACT  project,  a 
discussion  of  the  context  in  which  the  project  is  conducted,  and  a  description  of  the 
ASCACT  Integration  Working  Group  mandate  and  activities  are  also  presented. 
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1.0  INTRODUCTION 

It  is  anticipated  that  the  principal  threat  to  our  surface  ships  in  the  open  ocean  and 
littoral  operating  scenarios  of  the  future  will  be  from  air  attacks  by  sophisticated,  fast  anti¬ 
ship  missiles  fired  from  air,  surface,  subsurface  or  shore-based  platforms,  at  closely 
spaced  arrival  intervals,  and  by  aircraft  dropping  guided  or  unguided  bombs.  These  air 
attacks  are  characterized  by  great  rapidity  (requiring  very  short  reaction  time),  lethality  and 
multiple  simultaneous  engagements  in  a  very  complex  environment  (i.e.,  with  friends, 
foes,  neutrals,  etc.). 

The  approach  put  forward  by  the  Data  Fusion  and  Resource  Management  (DFRM) 
Group  at  the  Defence  Research  Establishment  Valcartier  (DREV)  to  help  counter  this  threat 
is  to  increase  the  Above  Water  Warfare  (AWW)  defence  capability  of  Canadian  Patrol 
Frigates  (CPFs)  through  the  development  of  a  real-time,  semi-automated  advisory  decision 
support  system.  Such  a  system  must  continuously  take  in  data  from  the  ship’s  sensors  and 
other  information  sources,  build  an  accurate  AWW  tactical  picture  as  quickly  as  possible, 
provide  the  most  likely  interpretation  of  the  tactical  situation,  suggest  options  to  defend  the 
ship  using  the  best  possible  combination  of  hardkill/softkill  weapons  or  other  defensive 
means  (e.g.,  suggest  an  optimal  sequence  of  sensor  and  weapon  allocations)  and  present 
fused  information  and  decision  support  analysis  results  with  the  opportunity  for  the 
Commanding  Officer  and  AWW  team  to  accept/reject  recommended  actions/plans  in  a 
timely  manner,  and  coordinate  and  direct  execution  of  these  actions/plans. 

To  develop  this  decision  aid  system  approach,  many  R&D  investigations  in  the 
areas  of  shipboard  Multi-Sensor  Data  Fusion  (MSDF),  Situation  and  Threat  Assessment 
(STA)  and  Resource  Management  (RM)  have  been  conducted  over  the  last  few  years  by  the 
DFRM  group  at  DREV  and  its  contractors  and  collaborators  (industry  and  university), 
analyzing  and  demonstrating  different  MSDF/STA/RM  approaches,  algorithms  and 
techniques  for  the  CPF.  These  R&D  investigations  have  established  a  substantial 
technological  basis  by  addressing  a  broad  range  of  issues  concerning  the  application  of 
MSDF,  STA  and  RM  technologies  to  the  CPF. 

Previous  work  in  MSDF/STA/RM  clearly  indicates  that  these  future  naval  systems, 
built  using  a  combination  of  numerical  technologies  such  as  Kalman  filters  and  artificial 
intelligence  technologies  such  as  knowledge-based  systems,  will  have  severe  data  and 
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information  processing  requirements  placed  upon  them.  Warships  will  also  have  a 
requirement  for  a  rapid  and  simple  communication  medium  for  the  integration  of  combat 
system  computers.  The  Advanced  Shipboard  Command  and  Control  Technology 
(ASCACT)  project,  also  known  as  project  D6195,  has  been  setup  and  approved  in  1987 
with  the  objective  to  improve  shipboard  data  processing  capability  for  Command  and 
Control  Information  Systems  (CCISs)  by  developing  an  Advanced  Development  Model 
(ADM)  multiprocessor  testbed.  The  general  purpose  of  the  ASCACT  testbed  is  for  the 
integration  of  high  speed  Commercial  Off-The-Shelf  (COTS)  products  into  the  shipboard 
CCIS  in  order  to  resolve  the  envisioned  high  speed,  high  throughout,  data  base  intensive 
applications  of  the  future.  The  ASCACT  testbed  will  allow  investigations  to  occur  on  any 
combination  of  these  requirements.  The  ASCACT  project,  managed  by  the  Directorate 
Maritime  Ship  Support  (DMSS  8),  is  divided  into  four  phases  (i.e.,  Real-Time  Distributed 
Data  Base  Management  System  (RTDDBMS),  Human  Computer  Interface  (HCI)  Study, 
Development  of  VME  SHINPADS  Nodes,  and  Integration). 

DREV  staff  members  have  been  involved  in  the  RTDDBMS  Phase  of  the  project  as 
scientific  advisors.  Through  an  active  participation  in  the  ASCACT  Integration  Working 
Group  (AIWG),  the  DFRM  group  is  currently  providing  consulting  services  in  support  of 
the  preparation  for  the  Integration  Phase.  Due  to  the  increased  extent  of  DREV  resources 
required  for  the  successful  realization  of  the  ASCACT  testbed,  a  new  task  entitled: 
"Capture  of  the  ASCACT  Integration  Testbed  Requirements"  has  been  defined  to  provide 
the  required  support  for  the  project.  This  task  is  conducted  by  the  DFRM  group  with 
DMSS  8  as  the  sponsor. 

This  document  is  the  first  of  three  to  be  produced  by  DREV  as  deliverables  for  the 
task.  The  contents  of  this  first  document  respond  to  the  requirements  of  Activity  1  (i.e., 
"Identification  of  DREV's  R&D  Activities  Relevant  to  ASCACT")  as  specified  in  the  Task 
Description  Sheet  (TDS).  In  that  respect,  this  document  identifies  and  describes  the  R&D 
work  conducted  at  DREV  in  the  areas  of  MSDF,  STA  and  RM  that  can  potentially  be  used 
in  the  ASCACT  testbed  and  it  also  discusses  the  level  of  effort  to  port  that  technology  to 
ASCACT. 

A  major  objective  pursued  with  this  document  is  the  production  of  a  single 
reference  document  providing  all  the  baseline  information  for  any  of  the  project's 
participants  to  get  a  working  knowledge  of  the  past,  current  and  future  activities  relevant  to 
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the  project.  This  document  therefore  establishes  a  foundation  or  a  common  basis  for  the 
activities  of  the  task.  Hence,  in  addition  to  the  presentation  of  DREV's  R&D  outcomes,  the 
document  also  provides  an  overview  of  the  ASCACT  project,  a  discussion  of  the  context  in 
which  the  project  is  conducted,  and  a  description  of  the  AIWG  mandate  and  activities. 
Indeed,  many  of  the  considerations  addressed  in  this  document  result  from  the  AIWG 
activities. 

Chapter  2.0  describes  the  ASCACT  project  and  testbed.  Based  mostly  on  DMSS 
8's  internal  documentation  on  naval  command  and  control  technology  provided  to  DREV, 
the  aim  of  the  project  is  given  along  with  a  description  of  the  main  phases  of  the  project. 
ASCACT  is  identified  as  a  major  component  of  a  set  of  tools  and  activities  relevant  to  the 
development  and/or  acquisition  of  integrated  shipboard  C2  systems  for  the  CPF.  The 
integration  of  the  non-organic  information,  which  is  deemed  as  essential  to  the  ASCACT 
testbed,  is  also  discussed.  Finally,  the  matter  of  DND  support  for  the  project  is  briefly 
addressed. 

The  purpose  of  Chapter  3.0  is  to  identify  and  briefly  describe  the  R&D  work 
conducted  at  DREV  in  the  areas  of  MSDF,  STA  and  RM.  The  mission  of  the  DFRM 
research  group  is  first  introduced,  along  with  various  definitions  (i.e.,  data  fusion,  etc.) 
derived  and  adopted  by  the  DFRM  group  to  establish  the  scope  of  its  work.  The  outputs  of 
the  R&D  activities  of  the  group  are  then  summarized  and  discussed  for  each  research  area 
taken  individually,  followed  by  some  remarks  on  the  investigation  of  the  MSDF/STA/RM 
integration  issue.  The  discussion  of  these  R&D  results  also  includes  some  references  to 
current  work  (in  particular,  a  study  for  the  definition  of  a  conceptual  framework  for 
shipboard  CCISs  and  a  collaborative  project  with  the  industry). 

The  main  motivation  behind  a  real-time,  integrated  MSDF/STA/RM  implementation 
in  the  ASCACT  testbed  are  identified  and  discussed  in  Chapter  4.0.  The  specific  factors 
that  motivate  DREV's  use  of  this  testbed  are  first  discussed  with  respect  to  each  of  the  main 
areas  of  research  taken  individually  (i.e.,  MSDF,  STA  and  RM).  Then  the  integration 
aspect  is  addressed.  Finally,  the  rationale  for  the  selection  of  an  appropriate 
MSDF/STA/RM  integration  framework  is  presented,  along  with  a  first  high-level  cut  at  its 
design. 
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Finally,  Chapter  5.0  discusses  the  ASCACT  Integration  Working  Group  that  was 
established  by  DMSS  8  and  DREV  to  fulfill  a  jointly  identified  requirement  for  a  formal 
information  exchange  mechanism  between  the  two  organizations  about  R&D  issues 
relevant  to  ASCACT.  The  mandate,  membership  and  operations  of  the  group  are  briefly 
presented. 

The  activities  leading  to  the  production  of  this  document  were  performed  at  DREV 
between  November  1994  and  June  1995  under  both  PSC  12C,  Ship  Combat  System 
Integration,  and  task  0111T39A,  Capture  of  the  ASCACT  Integration  Testbed 
Requirements.  Within  the  new  thrust  based  nomenclature  adopted  by  the  CRAD  (Chief 
Research  And  Development)  organization,  the  continuation  of  these  activities  is  currently 
covered  under  thrust  l.a,  Integrated  Naval  Above  Water  Warfare  and  Shipboard  Command 
and  Control. 

The  overall  objective  of  this  thrust  is  to  enhance  the  ship  commander's  effectiveness 
in  understanding  and  reacting  to  the  current  situation.  In  that  respect,  the  thrust  addresses 
the  development  of  improved  individual  shipboard  assets  as  well  as  their  optimal 
integration  and  coordinated  use  for  integrated  surveillance,  ship  protection  and  combat 
direction.  It  includes  sensors,  softkill  weapon  systems  (i.e.,  countermeasures)  and 
platform-level  command  and  control.  Of  particular  concern  is  to  develop  expertise  and  cost 
effective  solutions  in  critical  areas  such  as  sensor  data  fusion  and  the  integration  of 
information  from  non-organic  assets  (i.e.,  local  and  wide  area  data  fusion),  situation  and 
threat  assessment,  the  coordination  of  shipboard  surveillance  and  weapon  systems 
(through  resource  management),  interoperability  and  computer  networking  and 
architecture.  The  components  of  this  thrust  individually  constitute  critical  technology  areas 
for  maritime  defence  capability;  collectively  they  involve  the  examination  of  equally  critical 
issues  that  arise  in  system  integration. 

The  delivery  strategy  for  thrust  l.a,  touching  as  it  does  on  R&D  in  a  number  of 
technology  areas,  is  multifaceted  and  includes: 

•  CRAD  in-house  R&D  in  critical  aspects  of  component  technology  areas, 

•  access  and  further  development  of  industrial  expertise  through  R&D 
contracting, 

•  technology  transfer  to  industry, 
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•  collaborative  R&D  partnerships  with  industry  and  university, 

•  international  collaboration  and  information  exchange,  and 

•  direct  exploitation  of  new  technology  coming  from  the  thrust  through 
timely  insertion  in  the  fleet,  e.g.,  CPF  mid-life  upgrade,  life-cycle 
improvements  to  sensor  suites,  shipboard  processors,  navigation  and 
communication  equipment. 

In  applicable  areas  and  where  required,  design,  implementation  and  test  of 
prototypes  leading  to  proof-of-concept,  and  further  work  on  component  simulators, 
testbeds  or  field  trials,  are  pursued  via  industrial  partnership  and  support.  Technology 
proof-of-concept  involves  the  use  of  standards  and  Commercial  Off-The-Shelf  (COTS) 
technology,  as  necessary,  so  as  to  optimize  flexibility  and  cost  at  the  deployment  stage. 
This  strategy  is  also  a  prerequisite  for  achieving  the  required  operational  interoperability 
with  other  national  and  allied  systems  both  ashore  and  afloat. 

With  respect  to  the  R&D  activities  described  in  this  document,  DREV  provides 
expertise  under  thrust  1  .a  in  the  areas  of  command  and  control  information  systems, 
including  multi-sensor  data  fusion,  situation  and  threat  assessment,  response  coordination 
through  resource  management,  software  architectures  and  real-time,  high-performance 
distributed  computing. 
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2.0  THE  ASCACT  PROJECT  AND  TESTBED 

This  chapter,  based  mostly  on  DMSS  8's  internal  documentation  on  naval 
command  and  control  technology  provided  to  DREV,  gives  a  brief  description  of  the 
Advanced  Shipboard  Command  and  Control  Technology  (ASCACT)  project,  also  known 
as  project  D6195,  that  is  managed  from  within  DMSS  8.  The  aim  of  the  project  is  given 
along  with  a  description  of  the  main  phases  of  the  project. 

This  chapter  also  gives  some  information  on  the  context  in  which  the  ASCACT 
activity  is  conducted.  In  particular,  the  project  is  identified  as  a  major  component  of  a  set  of 
tools  and  activities  relevant  to  the  development  and/or  acquisition  of  integrated  shipboard 
C2  systems  for  the  CPF.  A  basic  concept  in  ASCACT  integration  is  one  of  formulating  an 
approach  that  maximizes  flexibility  and  minimizes  cost  in  an  evolutionary  approach.  This 
fundamental  concept  is  first  introduced  in  section  2.4,  discussing  the  development  in 
ASCACT  of  a  VMEbus  SHINPADS  node.  Additional  details  about  this  evolutionary 
approach  are  then  given  in  section  2.6.4,  in  the  context  of  a  discussion  of  the  Engineering 
Testbed  concept  proposed  by  DMSS  8.  Finally,  the  integration  of  the  non-organic 
information,  which  is  deemed  as  essential  to  the  ASCACT  testbed,  and  the  matter  of  DND 
support  for  the  project  are  both  briefly  addressed. 

2.1  Aim  of  the  ASCACT  Project 

It  is  anticipated  that  future  CCISs  for  the  Navy  will  have  severe  information 
processing  requirements  placed  upon  them  in  at  least  the  following  areas: 

•  shipboard  sensor  data  fusion; 

•  situation  and  threat  assessment; 

•  naval  resource  management;  and 

•  real-time  tactical  data  management  (e.g.,  the  management  of  organic  and 
non-organic  information  in  concert  with  the  integration  of  NTCS-A). 

To  meet  the  communication  requirements  of  these  advanced  functions,  it  is  expected 
that  naval  platforms  of  the  Maritime  Forces  will  also  have  a  requirement  for  a  rapid  and 
simple  communication  medium  for  the  integration  of  combat  system  computers.  The 
present  SHINPADS  serial  data  bus  which  provides  this  function  in  CPF  and  TRUMP 
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ships  will  then  need  to  be  improved  to  accommodate  the  next  generation  of  32/64-bit 
computers  now  under  development  and  on  which  these  advanced  functions  will  run.  This 
translates  into  a  requirement  for  a  combat  system  integration  medium  to  meet  more  stringent 
control  and  reaction  requirements  in  the  near  and  long  terms. 

In  this  context,  the  objective  of  the  ASCACT  project  is  to  improve  shipboard  data 
processing  capability  for  CCIS  systems  by  developing  an  Advanced  Development  Model 
(ADM)  multiprocessor  testbed.  This  testbed  will  be  used  to  investigate  the  adaptation  of 
advanced  commercial  data  processing  and  management  technology  for  military  applications 
(i.e.,  it  will  allow  the  development  and  testing  of  open  systems  compliant  COTS/GOTS 
products  for  potential  use  on  the  CPF).  In  particular,  the  ADM  testbed  developed  during 
this  project  will  be  used  to  investigate,  integrate,  test  and  evaluate  various  issues  such  as: 

•  future  additions  to  the  present  SHINPADS  system, 

•  an  enhanced  SHINPADS  node, 

•  examine  methods  to  ensure  compatibility  with  modern  high-performance 
backplanes  (e.g.,  SCI/RT), 

•  advanced  CCIS  concepts  such  as  MSDF/STA/RM, 

•  CCIS  performance  evaluation  methodology  and  metrics, 

•  generation  of  CPF  threat  scenarios  combined  with  open  and  closed-loop 
stimulation, 

•  real-time  distributed  database  systems, 

•  CCIS  Human  Computer  Interface  (HCI), 

•  etc. 

As  a  proof  of  concept  of  the  ASCACT  testbed,  an  integrated  MSDF/STA/RM 
baseline  application  will  be  implemented  as  a  distributed  real-time  system.  The  testbed  will 
help  to  establish  its  real-time  requirements  on  speed,  responsiveness,  predictability, 
timeliness,  etc.  At  the  same  time,  the  testbed  must  also  provide  a  capability  to  evaluate 
various  measures  of  effectiveness  for  this  MSDF/STA/RM  baseline  application. 

The  ASCACT  project  is  divided  into  four  phases.  These  are: 

Phase  1  -  Real-Time  Distributed  Data  Base  Management  System  (RTDDBMS). 

Phase  2  -  Human  Computer  Interface  (HCI)  Study. 

Phase  3  -  Development  of  a  VMEbus  SHINPADS  Node. 
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Phase  4  -  Integration. 

Each  phase  will  be  briefly  discussed  in  the  following  sections.  Note  that  the 
RTDDBMS  and  HCI  phases  look  at  discrete  aspects  of  the  shipboard  CCIS  requirements, 
whereas  the  Integration  phase  will  not  only  address  the  integration  of  the  first  two  phases, 
but  also  the  overall  architecture  of  future  shipboard  CCISs.  Note  also  that  the  infoirmation 
provided  in  this  chapter  is  not  definitive  since  the  direction  of  the  AS C ACT  project  must 
continuously  be  refined  in  order  to  reflect  the  requirements  imposed  upon  the  shipboard 
CCIS  from  both  internal  and  external  sources. 

2.2  Real-Time  Distributed  Data  Base  Management  System  (RTDDBMS) 

The  RTDDBMS  phase  of  ASCACT  has  been  designed  to  conduct  research  related 
to  the  processing  of  shipboard  tactical  data.  It  is  expected  that  future  shipboard  CCISs,  and 
the  related  sensor,  MSDF,  STA,  RM  and  weapon  subsystems,  will  have  challenging 
database  management  requirements.  As  enhanced  capabilities  to  shipboard  CCISs  are 
introduced,  including  the  import  and  export  of  selected  portions  of  the  non-organic  picture, 
tactical  databases  can  only  get  larger.  The  problems  associated  with  the  management  of 
tactical  data  are  only  likely  to  increase  in  size  and  complexity.  As  the  processing  power  and 
I/O  bandwidth  of  new  high-performance  computer  technology  increase,  future  designers 
will  likely  consider  placing  even  greater  demands  upon  the  tactical  data  processing 
capability  of  naval  combat  systems. 

Given  these  considerations,  some  major  issues  investigated  during  the  RTDDBMS 
phase  of  ASCACT  are: 

•  managing  large  transient  databases  (e.g.,  radar  and  ESM  contact  data, 
track  data,  etc.); 

•  database  querying  and  updating  in  real-time;  and 

•  geographically-distributed  databases. 

A  contract  for  the  development  of  the  RTDDBMS  was  awarded  in  April  1993  to 
Prior  Data  Sciences  Limited  of  Kanata,  Ont.  Their  design  solution  (Fig.  1)  maximizes  the 
use  of  Commercial-Off-the-Shelf  (COTS)  technology.  Central  to  their  design  is  the  Oracle 
7™  commercial  relational  database  management  product,  portions  of  which  are  distributed 
among  four  high-end  Sun  SparcStation™  workstations.  These  workstations  are 


FIGURE  1  -  Development  environment  for  the  RTDDBMS  phase 
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interconnected  via  a  FDDI  local  area  network.  Tactical  data,  reflecting  the  shipboard  CCIS 
track  database,  is  replicated  in  its  entirety  on  all  three  nodes  of  the  Target  environment  (in 
order  to  simulate  the  requirement  of  data  redundancy  for  a  survivable  CCIS). 

This  is  a  unique  solution  to  the  problem  of  database  management  for  naval 
shipboard  CCISs.  Typically,  COTS  software  would  be  prohibited  in  such  applications  due 
to  the  real-time  constraints  on  the  performance  of  the  overall  CCIS.  However,  with  the 
continuing  introduction  of  increasing  powerful  hardware  platforms  such  as  those  being 
used  in  this  phase  of  ASCACT,  an  almost  entirely  COTS  solution  is  likely  to  be  practical. 
Indeed,  results  of  the  contract  with  Prior  Data  Sciences  indicate  that  the  use  of  COTS  for 
naval  database  management  applications  is  very  feasible.  The  trials  have  been  completed 
and  the  delivery  to  DND  of  the  COTS  testbed  is  scheduled  for  late  1995. 

2.3  Human  Computer  Interfaces  (HCI)  Study 

In  this  phase  of  ASCACT,  the  HCI  as  it  relates  to  information  systems  such  as  the 
shipboard  CCIS  is  being  studied.  Currently,  no  comprehensive  HCI  specification  tailored 
specifically  to  naval  systems  exists.  Amongst  other  problems,  this  lack  of  guidance  risks 
unnecessarily  burdening  the  Navy's  limited  resources  with  the  repeated  development  of 
HCIs,  thereby  reducing  the  resources  available  for  developing  the  other  elements  of  each 
naval  system.  Many  have  voiced  a  desire  for  a  certain  amount  of  commonalty  among  the 
HCI  implementations  for  various  elements  of  the  C3I  architecture,  particularly  between  the 
shipboard  CCIS  and  the  ashore  CCIS. 

The  HCI  phase  is  to  determine  the  specific  requirements  of  the  HCI  for  combat  and 
marine  systems.  More  specifically,  the  HCI  phase  of  ASCACT  seeks  answers  to  the 
following  questions: 

•  What  hardware  and  software  technologies  should  be  used  in  the  design  of 
a  naval  information  system  HCI? 

•  What  elements  of  an  HCI  should  be  tightly  specified? 

•  What  elements  should  be  the  subject  of  less  restrictive  guidelines? 

Additionally,  the  impact  of  the  HCI  design  on  the  following  areas  is  taken  into 


account: 
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•  maintenance  costs; 

•  system  performance;  and, 

•  training  requirements. 

The  HCI  phase  comprises  two  sub-phases:  a  project  definition  study  and  an 
implementation  sub-phase.  The  project  definition  study  sub-phase  is  partitioned  into  five 
tasks.  These  are: 

Task  1  -  Survey  of  Current  Naval  HCI. 

Task  2  -  Report  on  Naval  HCI  Requirements. 

Task  3  -  Survey  of  HCI  Technologies. 

Task  4  -  Survey  of  HCI  Development  Environments. 

Task  5  -  Project  Definition  Plan  for  HCI  Implementation  Phase. 

A  contract  was  awarded  in  March  1994  to  Software  Kinetics  Ltd.  (SKL)  for  the 
project  definition  of  HCI  prototypes  to  be  used  in  a  study  of  future  HCIs  employable  with 
future  combat/marine  systems.  The  contract  was  completed  in  February  1995.  A  set  of 
reports  has  been  produced  by  SKL  under  this  contract.  However,  it  has  recently  been 
decided  to  put  the  HCI  Implementation  phase  on  hold  to  allow  time  to  take  the  results  of  the 
Naval  Combat  Operational  Trainer  (NCOT)  project  into  account.  As  a  result,  ASCACT 
could  ultimately  become  an  active  participant  in  this  larger  scope  project,  NCOT. 

2.4  Development  of  a  VMEbus  SHINPADS  Node 

As  it  was  implied  above,  the  Canadian  Navy  has  a  requirement  to  be  able  to 
integrate  COTS  applications  into  the  shipboard  CCS  of  the  CPF  class  ships.  In  order  to 
allow  the  development,  testing  and  integration  of  COTS/GOTS  workstations  into  the 
evolving  shipboard  CCS,  a  method  of  connecting  these  workstations  to  the  SHINPADS 
Serial  Data  Bus  (SDB)  is  required.  The  Versa  Module  Eurocard  (VME)  Single  Board  Node 
(SBN)  developed  under  the  ASCACT  project  is  a  means  that  could  fulfill  this  requirement. 

Figure  2  illustrates  how  future  systems  utilizing  COTS  products  may  be  interfaced 
to  the  CPF  and  TRUMP  (Tribal  class  Update  and  Modernization  Project)  CCS.  The 
present-day  CCS,  illustrated  on  the  bottom  of  Fig.  2,  still  possesses  a  significant  amount  of 
growth  capability  and  is  meeting  the  current  CPF  and  TRUMP  requirements.  In  the  future, 
performance  improvements  to  the  CCS  are  envisioned  to  be  through  high-speed  COTS 
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products,  illustrated  on  the  upper  left  hand  side  of  Fig.  2.  Some  possible  examples  of 
applications  which  will  utilize  this  philosophy  are  Multi-Sensor  Data  Fusion  (MSDF),  Joint 
Maritime  Command  Information  System  (JMCIS)  integration  to  CCS,  integration  of  new 
sensors  such  as  the  NATO  Improved  Link  Eleven  (NILE),  LINK  16,  TRUMP  ULQ 
6/SRD  501  Replacements,  etc. 

As  a  result,  a  means  needs  to  be  developed  to  effectively  integrate  these  systems 
into  today’s  CCS.  As  illustrated  on  the  upper  right  hand  side  of  Fig.  2.,  there  are  two 
suggested  methods  to  give  this  flexibility.  The  first  method  would  be  to  gain  access  to  the 
SDB  via  an  existing  node  that  has  a  spare  NTDS  interface.  The  second  method  would  be  to 
gain  access  via  a  SHINPADS  SDB  interface  card  (i.e.,  the  VME  SBN)  produced  for  the 
VMEbus.  This  bus  is  a  stable,  well  proven  backplane  standard  which  has  been  in  existence 
for  more  than  a  decade.  It  is  an  Institute  of  Electrical  and  Electronic  Engineers  (IEEE) 
standard  (IEEE  1014)  bus  which  is  an  integral  part  of  commercial  industry’s  Open  Systems 
Architecture  (OSA)  approach  for  designing  and  fielding  fault-tolerant  Real-Time  Systems 
(RTSs).  The  current  VMEbus  market  is  estimated  at  over  $3  Billion  annually.  Commercial, 
ruggedized  and  Mil-Spec  VMEbus  products  are  available  from  a  wide  variety  of  vendors  in 
Canada  and  the  United  States.  The  wide  vendor  support.  Open  Systems  Approach  and 
great  flexibility  of  design,  makes  VMEbus  an  ideal  choice  for  the  integration  of  COTS 
equipment  into  the  shipboard  CCS. 

Additional  details  about  the  evolutionary  approach  put  forward  for  the  shipboard 
CCIS  (Fig.  2)  are  given  in  section  2.6.4,  discussing  the  Engineering  Testbed  concept 
proposed  by  DMSS  8. 

2.5  Integration 

Phase  4  integrates  all  lessons  learned  from  each  activity  and  then  set  to  work  a 
fully-functional  testbed  using  the  hardware  of  the  RTDDBMS  (Fig.  1)  as  the  core. 

The  Integration  phase  of  ASCACT  is  scheduled  to  commence  with  a  Project 
Definition  Study  (PDS)  sub-phase  early  in  1996,  followed  immediately  by  an 
implementation  sub-phase.  The  purpose  of  the  PDS  sub-phase  will  be  to  refine  the  detailed 
engineering  approach  required  to  meet  the  goal  of  demonstrating  the  evolutionary  path  to 
future  CCISs.  More  precisely,  the  PDS  will  provide  the  complete  costing  and 
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recommended  implementations  and  also  provide  the  basis  for  the  SOW  for  the 
implementation  sub-phase. 

A  detailed  look  at  the  integration  phase  is  thus  somewhat  premature  at  this  moment. 
Nevertheless,  based  on  the  work  accomplished  so  far  by  the  ASCACT  Integration  Working 
Group  (see  Chapter  5.0),  the  remainder  of  this  chapter  gives  some  information  on  the 
context  in  which  this  phase  will  be  conducted  and  identifies  some  of  the  factors  that  must 
be  taken  into  account  for  the  ASCACT  project  Integration  Phase. 

2.6  CPF  CCIS  Development  Philosophy 

The  scope  of  the  issues  raised  within  the  many  R&D  activities  related  to  the 
potential  upgrades  of  the  CPF  CCIS  is  very  broad  and  far-reaching.  For  example,  they 
touch  on  complex  problems  in  real-time  systems  design  that  require  extensive  exploratory 
and  empirical  analyses,  as  well  as  studies  that  range  from  the  evaluation  of  theoretical 
concepts  (using  very  simple  computer  simulations  supporting  rigorous  mathematical 
analyses)  all  the  way  to  the  actual  testing  of  prototypes  during  live  military  exercises  (i.e., 
live  ship  trials).  Hence,  part  of  the  overall  shipboard  CCIS  analysis,  design,  development 
and  evaluation  process  involves  the  decision  regarding  the  most  appropriate  approach  or 
means  that  will  be  used  for  conducting  these  R&D  activities.  A  characterization  of  this 
broad  spectrum  of  possible  tools  and  approaches  is  shown  in  Fig.  3.  Generally,  as  is 
depicted  in  Fig.  3,  there  are  tradeoffs  in  selecting  one  approach  over  the  other.  The  most 
obvious  one  is  probably  the  level  of  operational  realism  obtained  versus  the  costs. 

The  ultimate  test  to  evaluate  the  military  value  of  a  CCIS  prototype  would  be  to  use 
it  in  live  military  exercises.  Such  an  environment  provides  reasonably  high  fidelity 
operational  conditions  since  the  real-world  physics,  human,  equipment  and  tactics/doctrine 
can  be  fully  taken  into  account.  However,  there  are  drawbacks  to  this  approach.  The 
system  designers  typically  cannot  have  full  control  of  the  events,  and  it  is  difficult  to  collect 
the  relevant  data.  For  example,  precise  truth  data  that  are  needed  for  MSDF  performance 
evaluation  can  be  hard  to  obtain  in  real-world  tests;  these  are  however  readily  available  in 
computer  simulations.  The  latter  typically  constitutes  very  controlled  research  environments 
that  offer  a  high  level  of  convenience  and  flexibility  at  low  cost.  Unfortunately,  digital 
simulations  cannot  always  adequately  represent  complex  real-world  phenomena  and  human 
behavior.  Specialized  field  data  collection  campaigns  can  be  a  good  compromise  between 


Military  Engineering  ASCACT  Simulated-  Proof-of-Concepts  Theoretical 

Exercises  Testbed  Integration  Real-time  Simulations  Concepts 

(Ship  Trials)  Testbed  Environment  (Off-Line)  (Math.  Analyses) 


FIGURE  3  -  Tradeoffs  in  analysis  /  modeling  /  evaluation  approaches  for  shipboard  CCIS 
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these  two  extremes.  Indeed,  this  approach  is  often  used  to  validate  computer  simulations. 
However,  such  trial  activities  can  rapidly  become  very  costly. 

Given  the  broad  scope  of  the  issues  raised  in  the  enhancement  activities  put  forward 
for  the  CPF  CCIS,  the  ASCACT  Integration  Working  Group  (see  Chapter  5.0)  has  been 
quick  to  realize  that  no  single  tool  or  activity  will  be  sufficient  to  provide  DND  with  all  the 
required  answers.  Hence,  the  R&D  environment  for  the  CPF  CCIS  must  rather  provide  a 
compatible  set  of  tools  and  testbeds  starting  with  the  DREV  testbeds  (e.g.,  the 
CASE_ATTI,  the  AAW  Simulator,  the  SRTE,  etc.)  for  basic  proof-of-concept  research, 
the  ASCACT  testbed  for  research  and  development,  some  combination  of  ASCACT  and  a 
shore  based  SHINPADS  bus  system  (CSTC,  SDTF  or  the  Engineering  testbed  being 
proposed  by  DMSS  8)  for  advanced  development,  and  the  shipboard  system  for  user 
feedback  and  trials.  Figure  4  shows  the  expected  tools/activities  loop  for  the  scientists, 
engineers  and  operators  involved  in  the  development  and/or  acquisition  of  integrated 
shipboard  C2  systems  for  the  CPF.  This  loop  is  based  on  current  activities  conducted  by 
both  DREV  and  DMSS  8,  and  those  planned  for  the  short  to  medium  term  future. 

The  R&D  process  for  the  CPF  CCIS  will  undoubtedly  require  several  iterations  in 
the  tools/activities  loop  of  Fig.  4,  where  the  results  of  one  iteration  lead  to  refinements, 
extensions  and  improvements  in  the  next  iteration.  It  is  also  evident  that  progress  will  both 
impact  and  be  impacted  by  naval  requirements  (i.e.,  the  customer  must  be  kept  involved 
during  this  iterative  process)  and  that  this  interaction  may  subsequently  even  help  in 
shaping  naval  doctrine.  As  such,  this  will  require  work  both  inside  and  outside  the 
immediate  scope  of  the  ASCACT  project.  The  following  sub-sections  give  some 
information  on  the  main  components  of  the  tools/activities  loop. 

2.6.1  Study  of  Shipboard  CCIS  Theoretical  Concepts 

In  the  past  few  years,  a  lot  of  research  effort  within  the  technology  base  program  of 
the  CCIS  Division  at  DREV  has  been  directed  towards  the  automation  of  C2  processes  for 
managing  the  information  and  allocating  the  resources  by  which  the  naval  commander  can 
exercise  command  and  control  in  actual  and  future  Above  Water  Warfare  (AWW) 
scenarios.  From  this  work,  three  critical  issues  can  be  put  in  perspective  for  the  evolution 
of  shipboard  CCIS:  sensor  data  fusion,  situation  and  threat  assessment,  and  resource 
management.  Chapter  3.0  discusses  this  R&D  work  being  conducted  at  DREV  and  briefly 
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FIGURE  4 -Tools/activities  loop  for  the  scientists,  engineers  and  operators 
involved  in  the  development  or  acquisition  of  integrated  shipboard 
CCIS  for  the  CPF 
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summarizes  the  main  results  that  have  been  obtained  so  far  in  the  areas  of  MSDF,  ST  A  and 
RM.  As  part  of  the  current  efforts,  the  conceptual  framework  activity  and  a  collaborative 
project  with  the  industry  are  also  described  in  Chap.  3.0. 

2.6.2  Proof-of-Concept  Simulation  Tools 

The  extremely  limited  availability  of  trial  data  to  support  algorithm  development  and 
MSDF/STA/RM  system  prototypes  represents  a  serious  detriment  to  the  Canadian  R&D 
community.  Many  research  programs  whose  focus  is  on  MSDF,  STA  or  RM  algorithm 
analysis  and  development  cannot  afford  to  incur  additional  costs  of  data  collection  for  the 
purpose  of  demonstrating  algorithms  with  real  data.  Alternatives  to  this  situation  include 
artificially  synthesizing  appropriate  data  from  trial  data  collected  under  non-standard 
conditions  (not  easy  to  do  in  a  convincing  manner),  or  to  employ  high-fidelity  simulators. 
This  last  option  has  been  retained  for  the  MSDF,  STA  and  RM  projects  at  DREV  since, 
most  of  the  time,  representative  simulated  data  may  be  sufficient  to  verify  or  validate 
MSDF/STA/RM  concepts. 

2.6.2.1  CASE_ATTI 

Reference  1  presents  an  overview  of  the  CASE_ATTI  (Concept  Analysis  and 
Simulation  Environment  for  Automatic  Target  Tracking  and  Identification)  algorithm-level 
simulation  testbed  that  has  been  developed  by  DREV  to  support  the  research  in  MSDF. 
CASE_ATTI  provides  a  highly  modular,  structured  and  flexible  hardware/software 
environment  necessary  to  study  and  compare  various  advanced  MSDF  concepts  and 
schemes  in  order  to  demonstrate  their  applicability,  feasibility  and  performance.  Reference 
1  also  discusses  how  CASE_ATTI  is  currently  being  used  to  support  the  development  and 
evaluation  of  advanced  sensor  data  fusion  concepts  in  the  context  of  the  CPF. 

2.6.2.2  AAW  Simulator 

A  multiple  ship  Anti-Air  Warfare  (AAW)  Simulator  has  also  been  developed  by 
DREV  for  studying  the  decision-making  of  the  knowledge-based  Threat  Evaluation  and 
Weapon  Assignment  (TEW A)  process  for  a  ship  that  is  attacked  by  anti-ship  missiles.  The 
twenty  modeled  entities  of  the  AAW  Simulator  were  designed  according  to  the 
specifications  of  Refs.  2-4  and  coded  in  SMALLTALK  80.  Acceptance  tests  for  these 
entities  are  currently  being  performed  on  the  simulator. 
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2.6. 2.3  SARA 

Reference  5  presents  the  design  of  a  flexible,  object-oriented,  generic  TEWA 
concept  demonstrator,  known  as  the  Situation  Assessment  and  Resource  Allocation 
(SARA)  tool,  that  has  been  developed  in-house  at  DREV.  Easily  adaptable  and  expandable, 
SARA  is  well-suited  to  investigate  concepts,  models  and  algorithms  relevant  to  situation 
assessment  and  resource  allocation  in  the  naval  AAW  context. 

2.6.2.4  SRTE 

The  CASE_ATTI,  AAW  Simulator  and  SARA  tools  mentioned  above  are  non-real¬ 
time  proof-of-concept  simulation  environments.  A  separate  means  is  thus  required  to 
investigate  the  real-time  aspects  of  the  CCIS  components  proposed  for  the  future. 

The  evaluation  of  the  real-time  performance  of  an  integrated  MSDF/STA/RM 
system  can  be  done  partially  by  analytical  methods  (e.g.,  queuing  theory).  There  are  also 
various  simulation  and  monitoring  tools  (e.g.,  Network  II. 5™,  NetMetrix™,  etc.)  that 
could  be  used.  However,  the  option  of  developing  a  Simulated-Real-Time  Environment 
(SRTE)  tool  that  would  provide  the  best  means  to  perform  non-intrusive,  repeatable 
performance  monitoring  at  the  instruction  level  of  a  real-time  application  is  currently  under 
investigation  (see  section  3.7.1). 

The  proposed  SRTE  tool  would  also  provide  a  means  to  investigate  MSDF,  STA 
and  RM  jointly  in  an  integrated  real-time  system,  whereas  the  CASE_ATTI,  AAW 
Simulator  and  SARA  tools  only  address  these  components  individually. 

2.6.2.5  Simulation  Tools  Compatibility 

The  CASE_ATTI,  AAW  Simulator  and  SRTE  tools  are  further  discussed  below  in 
Chapter  3.0.  Up  to  now,  the  various  research  tools  which  DREV  has  developed  and 
utilized  do  not  operate  well  together  nor  with  the  proposed  ASCACT  testbed.  The  level  of 
effort  to  integrate  portions  of  these  research  tools  into  the  ASCACT  testbed  needs  to  be 
evaluated.  This  will  be  done  as  part  of  the  ASCACT  Integration  Working  Group  activities. 
In  the  future,  it  is  desirable  that  DREV  research  performed  on  proof-of-concept  simulations 
be  conducive  to  portability  to  the  ASCACT  testbed  with  minimal  Non-Recurring 
Engineering  (NRE). 
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2.6.3  ASCACT  Integration  Testbed 

The  CCIS  integration  testbed  based  on  COTS  technology  to  be  developed  under  the 
ASCACT  project  has  already  been  introduced  above  in  this  chapter.  The  main  features  that 
characterizes  this  testbed  in  the  CPF  tools/activities  loop  are  the  real-time  aspect  and  the 
study  of  MSDF,  STA,  RM  and  other  C2  processes  jointly  in  an  integrated  fashion.  A 
preliminary  definition  of  an  integration  framework  for  this  testbed  is  discussed  below  in 
Chapter  4.0. 


2.6.4  Engineering  Testbed  for  Combat  System  Upgrades 

As  discussed  in  the  previous  sections,  future  shipboard  CCISs,  encompassing 
MSDF,  STA,  RM  and  other  C2  applications,  could  be  characterized  by  high  to  extremely- 
high  CPU  demands  and  processor  interconnect  bandwidth  requirements.  Given  the 
dynamic  nature  of  these  requirements,  it  is  essential  that  the  architecture  of  future  CCIS  be 
extremely  flexible.  It  is  also  assumed  that  cost  will  be  an  overriding  concern  in  almost  all 
implementation  decisions.  In  this  context,  designing  the  future  shipboard  CCIS  architecture 
as  an  evolution  of  the  present  architecture  would  allow  us  the  flexibility  of  an  evolutionary, 
incremental  upgrade  of  capability  as  money  becomes  available.  The  Engineering  Testbed 
discussed  below  is  of  paramount  importance  to  this  evolutionary  approach. 

2.6.4. 1  Current  CPF  CCIS  Architecture 

Present  systems  onboard  CPFs  are  based  on  Standard  Digital  Equipment  (SDE) 
such  as  the  UYC-503  node,  the  UYK-507  processor,  the  UYQ-505  combined  node  and 
processor,  and  the  SHINPADS  Serial  Data  Bus  (SDB).  The  CPF  CCIS  architecture  is 
distributed,  with  individual  components  communicating  with  each  other  over  the  SDB. 
This  SDB,  though  equal  in  raw  speed  (bandwidth)  to  that  of  modest  LAN  standards  such 
as  Ethernet  at  10  Mbps,  is  a  sophisticated  multiple-redundant,  fault-tolerant,  real-time 
processor  interconnect.  Its  primary  purpose  is  not  as  much  the  transfer  of  large  volumes  of 
data  from  processor  to  processor,  but  the  orderly  control  of  the  many  attached  SDE 
processors.  Indeed,  it  is  estimated  that  the  SDB  is  only  loaded  to  approximately  10-15%  of 
its  modest  bandwidth. 
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2.6.4.2  Engineering  Testbed  Concept 

Given  the  current  CCIS  architecture  described  above,  and  keeping  in  mind  the 
rationale  for  an  evolutionary  approach  to  any  CPF  enhancement,  what  is  needed  to  support 
CPF  combat  system  upgrades  is  an  R&D  environment  that  allows  for: 

•  the  testing  of  integration  techniques  for  COTS  hardware/software; 

•  the  integration  of  RTDDBMS  and  other  ASCACT  products; 

•  the  integration  of  future  systems  (e.g.,  AAW  upgrade,  WANTAP, 
MSDF/STA/RM,  etc.); 

•  technology  upgrade  for  displays,  processors  and  peripherals. 

Taking  these  considerations  into  account,  the  concept  of  an  Engineering  Testbed 
has  been  proposed  by  DMSS  8.  The  incremental  approach  for  the  shipboard  CCIS 
enhancement,  including  this  concept  of  an  Engineering  Testbed,  is  shown  in  Fig.  2. 

To  help  meet  their  demanding  requirements  on  the  CPF  data  processing  capability, 
the  new  C2  component  systems  would  be  integrated  by  adding  clusters  of  computers  (such 
as  the  cluster  developed  as  part  of  the  ASCACT  integration  testbed)  to  the  current 
architecture.  In  terms  of  high  data-rate  transfers,  it  is  expected  that  the  SHINPADS  SDB 
could  not  have  the  reserve  bandwidth  in  order  to  accommodate  these  future  systems' 
requirements.  In  spite  of  this  however,  the  bandwidth  of  the  SDB  is  not  a  problem.  As 
previously  mentioned,  the  SDB  has  been  designed  as  a  control  bus,  and  should  be  retained 
for  this  purpose  in  future  shipboard  CCISs.  This  approach  has  the  concomitant  advantage 
of  cost  reduction  since  strip-out  and  replacement  of  the  SDB  would  not  be  anticipated  as  a 
requirement  at  CPF  mid-life.  High-bandwidth  communications  within  each  cluster  would 
presumably  be  handled  by  some  other  interconnect  such  as  the  Scalable  Coherent  Interface 
for  Real-Time  (SCI/RT)  applications  which  is  expected  to  be  capable  of  8,000  Mbps.  A 
simple  connection  to  the  SDB  would  then  allow  these  clusters  to  be  monitored  or  controlled 
in  much  the  same  way  as  any  sensor  or  weapon  system  is  presently  controlled  via  the  SDB. 

The  connection  of  new  systems  to  the  SDB  would  be  either  through  any  spare 
NTDS  port  on  existing  nodes,  or  via  a  developed  commercial  node  card  such  as  the 
VMEbus  node  card  considered  in  Phase  3  of  ASCACT.  As  new  systems  are  injected,  the 
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CCIS  system  would  evolve  in  a  carefully  planned  manner.  This  corresponds  to  an 
evolutionary  concept  as  opposed  to  a  revolutionary  concept. 

Among  the  concrete  benefits  that  DND  would  gain  from  the  availability  of  the 
proposed  Engineering  Testbed  are  the  following: 

•  DND  would  be  in  a  position  to  insert  new  technology  on  the  ships 
(schedule  reduction); 

•  it  would  allow  for  the  development  and  testing  of  new  operational 
concepts  for  the  combat  system  (reduction  of  the  technical  risk); 

•  it  would  allow  the  preparation  of  valid  and  realistic  performance 
specifications  for  the  combat  system  (reduction  of  the  technical  risk); 

•  it  would  allow  for  a  systematic  approach  to  making  changes  to  the  combat 
system  (all  R&D  projects  could  use  the  Engineering  Testbed); 

•  it  would  allow  for  the  testing  of  different  options,  algorithms,  etc.  (e.g., 

MSDF,  STA,  RM), 

•  it  could  be  used  for  overflow  software  maintenance  (e.g.,  for  the 
maintenance  of  the  Standard  Distributed  Executive  (SDX)  software 
module  of  the  CPF);  and 

•  a  near  term  use  could  be  the  integration  of  JMCIS,  EWCP,  AAW. 

The  Engineering  Testbed  would  be  set  up  to  ran  Halifax  class  software  systems. 

2.6.4.3  Engineering  Testbed  Development 

The  proposed  Engineering  Testbed,  shown  in  Fig.  5,  must  be  based  on  the  present 
SHINPADS  SDB,  and  incorporate  enough  of  the  present  SDE  to  effectively  demonstrate 
compatibility  of  new  systems  with  the  present  architecture.  This  would  prove  the 
evolutionary  approach  to  upgrading  shipboard  CCIS  capabilities.  The  two  CPF  facilities 
listed  below  meet  these  requirements: 

•  CSTC  This  is  the  Combat  Systems  Test  Center  facility  currently  located 

in  Halifax.  It  was  previously  called  CSTSF  (Combat  Systems 
Test  and  Support  Facility)  before  its  move  from  Montreal  (Loral 
Canada)  to  Halifax. 
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•  SDTF  This  is  the  Software  Development  and  Test  Facility  previously 
located  in  Montreal  (Loral  Canada).  It  has  also  been  moved  to 
Halifax. 

However,  these  facilities  are  being  used  for  training  and  maintenance  almost  24 
hours/day.  Clearly,  the  R&D  oriented  Engineering  Testbed  cannot  be  shared  with  training 
or  normal  system  maintenance  in  steady  state.  DREV  and  DMSS  also  need  control  of  the 
Engineering  Testbed  for  major  system  changes. 

Hence  new  developments  are  required  to  provide  the  Engineering  Testbed  to  the 
R&D  community.  However,  although  the  rationale  for  the  Engineering  Testbed  is 
becoming  well  established,  its  funding  and  development  still  need  to  be  approved. 

Obviously,  a  cost  effective  approach  is  needed.  As  an  initial  step  toward  a  potential 
solution,  DMSS  8  is  currently  investigating  the  repatriation  of  the  four-node  system  testbed 
currently  located  at  Loral  Canada's  facilities  in  Ottawa.  A  task  has  been  issued  to  Loral 
Canada  to  prepare  a  B-Class  cost  estimate  for  upgrading  the  constituent  SDE  of  this  system 
from  a  UYK-502  architecture  to  a  UYK-507/UYQ-505  processor  suite  in  order  to  reflect 
the  baseline  system  architecture  of  CPFs.  This  task  should  be  completed  by  August  1996. 
DMSS  8  is  also  investigating  the  option  of  a  cost  sharing  with  Loral  Canada  to  develop  the 
Engineering  Testbed.  Talks  are  in  the  preparation  stage  and  a  significant  amount  of  work  is 
still  required  to  bring  it  to  fruition.  Assessing  the  timeline  for  this  development  (assuming 
the  shared-cost  option  is  acceptable),  it  is  envisioned  to  have  the  Engineering  Testbed  in 
place  by  FY  97. 

As  a  final  remark,  it  is  expected  that  the  Engineering  Testbed  could  eventually 
reside  at  DREV,  NETE  or  at  a  contractor  site. 

2.6.5  CPF  Trials 

Given  the  level  of  realism  that  they  provide  for  system  design  and  evaluation,  high- 
quality  ship  trials  are  a  goal  that  the  Canadian  R&D  community  should  be  seeking.  With 
respect  to  MSDF  R&D  for  example,  there  is  an  urgent  need  for  data  sets  from  real  sensors 
and  targets,  even  though  such  sensor-target  pairs  may  only  be  representative  for  a  specific 
variety  of  applications.  To  date,  however,  very  little  calibrated  and  simultaneously  collected 
data  on  targets  of  interest  exists.  This  is  especially  true  for  the  case  of  dissimilar  sensors. 


P435278.PDF  [Page:  41  of  128] 


UNCLASSIFIED 

25 


Only  a  few  organizations,  almost  exclusively  located  in  the  US  or  Europe,  have  invested  in 
the  collection  of  such  trial  data.  Given  various  political  factors  and  the  cost  of  such 
collection  operations,  these  data  are  usually  very  sensitive  and  typically  become 
(appropriately)  proprietary.  As  a  result,  most  of  the  time  MSDF  designers  must  content 
themselves  with  trial  data  that  have  only  a  limited  relevance  to  MSDF.  One  should  note  that 
the  situation  is  similar  with  respect  to  the  other  C2  processes. 

Despite  the  huge  amount  of  efforts  (human  resources,  money,  etc.)  that  the  setup 
and  performance  of  high-quality  ship  trials  represents,  these  trials  constitute  the  most 
important  component  of  the  CPF  CCIS  tools/activities  loop  since  they  represent  the  ultimate 
means  by  which  the  military  customer  can  evaluate  a  prototype  and  provide  feedback  to  the 
scientific  and  engineering  communities,  ensuring  that  the  final  product  does  address  the 
identified  needs  of  the  Forces. 

2.7  Integration  of  Non-Organic  Information 

The  ASCACT  project  (and  equivalently  its  associated  integration  testbed)  has  been 
conceived  to  address  data  processing  R&D  issues  relevant  to  the  tactical  CCIS  of  CPFs. 
Moreover,  the  emphasis  for  the  first  baseline  application  to  be  implemented  and 
investigated  with  the  ASCACT  testbed  is  currently  given  to  the  management  of  the  organic 
information  for  the  CPF  (i.e.,  MSDF/STA/RM  based  on  CPF  organic  resources): 
However,  the  ASCACT  project  team  also  considers  other  aspects  (e.g.,  the  integration  of 
the  non-organic  information,  the  strategic  issues)  associated  with  the  global  C2  architecture 
put  forward  for  the  Forces. 

Some  naval  C3I  architecture  requirements,  such  as  the  MCOIN  3  and  NTCS-A 
systems,  are  themselves  interrelated,  and  in  turn  drive  the  external  interface  requirements  of 
the  shipboard  CCIS.  Hence,  R&D  for  the  shipboard  CCIS  must  take  into  account  the 
issues  related  to  the  various  CCISs  ashore.  In  particular,  in  terms  of  the  future  expansion 
of  the  ASCACT  testbed,  the  hooks  to  evolve  from  a  tactical  only  system  to  a  system  that 
also  operates  on  strategic  information  must  be  identified.  For  example,  the  potential 
input/output  requirements  for  the  MSDF/STA/RM  baseline  application  running  on  the 
testbed  must  be  identified. 
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The  next  two  sections  briefly  discuss  two  major  activities  that  are  closely  monitored 
by  the  ASCACT  team  in  order  to  ensure  that  the  ASCACT  testbed  will  remain  in  line  with 
progress  made  during  the  CF  global  C2  architecture  evolution. 

2.7.1  The  Management  of  Organic  and  Non-Organic  Information  in 
the  Maritime  Environment1 

Modern  warships  carry  a  multitude  of  types  of  equipment  including  radar,  ESM, 
and  E-O  which  provide  information  allowing  the  commander  at  sea  to  gain  a  level  of 
situational  awareness.  This  type  of  information  can  be  defined  as  organic  information,  as  it 
is  controlled  and  collected  by  assets  under  his  direct  control.  This  organic  information  is 
sufficiently  timely  and  accurate  to  be  used  in  real-time,  responsive  systems.  Consequently, 
it  can  be  used  to  produce  a  local  Tactical  Picture  which  supports  all  of  the  commander's 
activities  at  sea. 

The  commander  ashore  equally  has  the  need  to  obtain  information  on  a  more  global 
scale.  Shore-based  systems  have  been  developed  to  collect,  store  and  disseminate  a  vast 
amount  of  information  in  an  attempt  to  provide  some  sort  of  global  situational  awareness. 
Some  of  this  information  is  also  of  considerable  interest  to  the  sea-going  commander. 
However,  this  information  is  collected  by  agents  not  under  his  direct  control.  Such  a  source 
of  information  is  referred  to  as  "non-organic".  It  brings  to  the  sea-going  commander  a  new 
problem  of  how  to  integrate  this  information  with  his  own  organic  information.  Within  the 
AUSCANNZUKUS  organization,  this  has  led  to  the  term  "Management  of  Organic  and 
Non-organic  Information  in  the  Maritime  Environment"  (MONIME). 

The  advancement  of  communications  capacity  and  the  development  of  data  transfer 
technologies  inevitably  have  made  it  possible  to  provide  the  commander  at  sea  with  access 
to  a  new  and  increasing  amount  of  non-organic  information  available  from  world-wide 
sensors.  The  first  truly  automated  attempt  at  providing  the  commander  at  sea  with  access  to 
non-organic  information  was  the  USN  Joint  Operational  Tactical  System  (JOTS).  JOTS 
can  be  seen  as  one  solution  to  managing  non-organic  information.  When  first  conceived  it 
was  a  solution  to  providing  access  to  a  very  large  database  and  displaying  the  information 


1  The  information  in  this  section  has  been  extracted  from:  AUS-CAN-NZ-UK-US  Naval  C3  Group  /  C2 
Committee,  "Handbook  5:  The  Management  of  Organic  and  Non-Organic  Information  in  the  Maritime 
Environment",  DRAFT,  Issue  1.1,  17  March  1995,  UNCLASSIFIED. 
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in  an  easily  understood  format.  The  user  requirement  was  loosely  stated  and  the 
requirement  to  integrate  organic  information  was  not  identified. 

Non-organic  information  has  characteristics  which  make  it  quite  different  from 
organic  information.  It  is  less  timely,  reduced  in  accuracy,  differently  structured  and  has 
differing  identification  confidence  levels.  For  these  reasons,  it  can  not  easily  be  integrated 
into  the  existing  organic  "Tactical"  picture  which  traditionally  has  been  used  with 
confidence  to  employ  force  or  unit  weapons  and  sensors.  The  inclusion  of  non-organic 
information  into  the  organic  "Tactical"  picture  had  a  propensity  to  confuse  and  clutter  the 
original  picture.  As  a  result,  the  non-organic  information  was  displayed  separately  and 
primarily  used  as  a  planning  aid  over  a  larger  geographic  area.  From  this  arose  the  concept 
of  the  Wide  Area  Picture  (WAP).  This  picture  becomes  even  more  useful  when  shared  by  a 
number  of  naval  forces  over  a  large  area  and  is  a  vital  command  decision  aid.  For  this  to 
occur  there  needs  to  be  an  assurance  of  a  common  Maritime  Tactical  Picture  (MTP).  To 
ensure  its  timeliness,  the  MTP  must  be  exchangeable  via  an  automated  information 
exchange  system  similar  to  data  links  which  have  traditionally  conveyed  the  organic  tactical 
picture. 


Currently,  this  stand  alone  display  presently  evolving  within  the  USN  under  the 
Joint  Maritime  Command  Information  System  (JMCIS)  concept,  has  become  one  solution 
to  MONIME.  There  have  been  considerable  advances  in  timeliness,  quality  and  capacity 
since  JOTS  was  first  fielded.  Despite  advances  in  software,  and  the  hardware  displaying 
information  to  the  user,  there  has  been  no  change  in  the  fundamental  method  of  MONIME. 

In  1993,  the  AUSCANNZUKUS  Supervisory  Board  commissioned  an  Ad  Hoc 
Working  Group  (AHWG)  to  investigate  MONIME.  The  AHWG  evolved  a  strategy  of 
using  simulation,  LIVEX,  and  analysis  techniques  to  quantify  the  effectiveness  of  the 
management  processes.  Much  information  has  been  determined  from  these  efforts  and  a 
document.  Handbook  5,  has  been  created  to  collate  that  work.  Handbook  5  seeks  to 
describe  the  need  for,  use  and  management  of  the  MTP  and  where  possible  provide  policy 
and  standards  for  operations,  and  to  lay  down  the  guidelines  that  will  promote  Allied 
interoperability.  The  Handbook  is  reviewed  annually  and  is  intended  to  be  a  living,  user 
friendly  document.  The  potential  users  of  Handbook  5  may  include  those  writing 
Operational  Requirements,  Procurement  Agencies,  Research  and  Development  Agencies, 
and  Fleet  Commanders.  It  addresses  technical  and  procedural  details  leading  to  the 
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acquisition  of  new  systems  which  are  interoperable.  It  seeks  to  promote  the  rapid 
introduction  of  new  technology  to  produce  an  increasingly  better  tactical  picture  without  the 
traditional  procurement  delays. 

2.7.2  National  Level  Command  and  Surveillance  R&D  Activities2 

Many  aspects  concerning  the  development  of  the  global  C2  architecture  proposed 
for  the  Forces  are  addressed  by  the  CRAD  organization  under  the  Thrust  5. a  entitled: 
National  Level  Command  and  Surveillance.  This  thrust  deals  with  national-level  C2 
functions  (which  are  by  nature  joint  and  often  combined)  and  the  associated  strategic,  wide- 
area  surveillance  sensor  systems  (radar,  electro-optics,  underwater  acoustics  and 
electromagnetic).  This  includes  theater  level  activities  in  which  the  CF  is  deployed  to  other 
areas  in  the  world.  The  thrust  will  integrate  sensor  information  from  the  various  sources 
available  (Canadian  military,  allies  and  non-military)  to  form  a  joint  intelligence  picture  and 
to  enable  commanders  and  staff  to  monitor  the  overall  operational  situation.  The  system 
needed  to  support  such  a  concept  must  provide  a  high  level  of  information  sharing  through 
automated  interoperability  between  the  various  force-level  strategic  C2  systems  (MCOIN3 
(Maritime  Command  Operational  Information,  Mark  3),  AFCCIS  (Air  Force  CCIS)),  their 
interaction  with  CFCCOIS  (CF  Command  and  Control  Operational  Information  System) 
and  more  broadly  with  Other  Government  Departments  (OGDs)  and  allies.  Links  to  more 
tactical  systems  such  as  LFIS  are  also  considered.  Continental  (NORAD)  coordination  and 
support  for  contingency  or  deployed  operations  in  a  global  context  are  key  aspects  of  this 
thrust. 


The  DCDS  has  recently  directed  that  the  implementation  of  an  effective  CF  C2 
system  be  given  high  staffing  priority.  The  initial  task  is  to  upgrade  the  National  Defence 
Operations  Center  (NDOC)  automated  systems  and  to  explore  and  propose  solutions  to 
long-standing  deficiencies.  Furthermore,  in  response  to  the  1994  White  Paper  on  Defence, 
the  Forces  Commands  will  be  centralized  in  NDHQ  (Ottawa)  and  will  require  direct 
interaction  with  NDOC. 

In  parallel  with  this  effort,  the  Navy  has  plans  to  develop  a  coordinated  shore  and 
shipboard  command,  control,  communications  and  intelligence  (C3I)  system  to  enable  all 

2  The  information  in  this  section  has  been  extracted  from:  Otis,  G.  et  al,  "Thrust  5.a  -  National  Level 
Command  and  Surveillance",  Preliminary  Thrust  Business  Plan  (5  years),  DREV,  2  May  1995, 
UNCLASSIFIED. 
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naval  shore  HQs  to  automatically  collect,  display,  evaluate  and  disseminate  information  in 
support  of  a  wide  area  or  fleet  level  picture.  The  proposed  system  will  also  be  required  to 
link  and  interact  with  the  Canadian  Maritime  Network  (CanMarNet)  for  coordinated 
missions  with  OGDs  (Coast  Guard,  Fisheries  and  Oceans,  RCMP)  for  law  enforcement, 
fishing  zone  surveillance,  etc.  CanMarNet  will  permit  departments  with  maritime  interests 
to  participate  in  the  development  and  use  of  the  consolidated  surface  picture  on  a  24/7 
basis.  DND  input  will  be  provided  from  MCOIN3. 

In  the  surveillance  sensor  area,  the  Maritime  R&D  Overview  Group  (MRDOG) 
identified  Strategic  Surveillance  Systems  as  a  high  priority  requirement  in  its  most  recent 
Way-ahead  Paper.  The  surface  coverage  can  be  provided  by  HF  radars  in  the  inner  coastal 
zone,  which  can  be  complemented  in  the  middle  and  outer  zones  by  fixed  or  deployable 
acoustic  sensor  systems  and  by  bottom-mounted  electromagnetic  sensor  arrays  in  strategic 
choke  points. 

The  thrust  will  support  the  common-core  technologies  efforts  (standardization  and 
interoperability)  pursued  by  DIMPPC,  as  mandated  by  DISO  and  the  DCDS.  The  thrust 
also  provides  direct  support  to  CF  procurement  projects  such  as  ISX  (Intelligence  and 
Security  Complex  -  G  1671),  MCOIN  3  (Maritime  Command  Operational  Information, 
Mark  3  -  M  1772),  CFCCOIS  (CF  Command  and  Control  Operational  Information  System 
-  G  2469),  etc. 

2.8  DND  Support  for  the  ASCACT  Project 

The  Program  Planning  Proposal  (PPP)  for  D6195  was  approved  by  ADM(Mat)  in 
February  1987  and  entered  into  the  Defence  Services  Program  (DSP)  as  "D"  capital.  The 
Program  Change  Proposal  (PCP)  was  submitted  and  approved  by  the  Program  Control 
Board  Sub-Committee  (PCBSC)  in  October  1990  and  by  the  Minister  in  December  1990. 
Changes  in  scope  for  the  D6195  project  were  sought  and  gained  with  Senior  Review  Board 
(SRB)  approval  in  June  1995,  which  still  remain  valid  today. 

The  support  for  this  project  comes  from  DNR,  DSAM  and  DMSS  which  are  all 
members  of  the  SRB.  Command  and  Control  is  the  number  one  priority  research  issue  as  it 
stands  now,  as  specified  by  the  Commander  MARCOM.  Given  the  priority  that  the 
maritime  community  places  upon  C3I,  the  ASCACT  project  can  be  viewed  as  extremely 
desirable. 
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3.0  R&D  RESULTS  ON  SHIPBOARD  C2  SYSTEMS  INTEGRATION 

In  the  past  few  years,  a  lot  of  effort  within  the  CCIS  Division  at  DREV  has  been 
directed  towards  the  automation  of  C2  processes  for  managing  the  information  and 
allocating  the  resources  by  which  the  naval  commander  can  exercise  command  and  control 
in  actual  and  future  Above  Water  Warfare  (AWW)  scenarios.  Figure  6  shows  an 
appropriate  conceptual  framework  describing  the  C2  process  in  the  context  of  a  single  naval 
platform  (or  single  ship).  This  framework  puts  in  perspective  three  critical  processes  for  the 
evolution  of  naval  C2:  Multi-Sensor  Data  Fusion  (MSDF),  Situation  and  Threat 
Assessment  (STA)  and  Resource  Management  (RM).  The  purpose  of  this  chapter  is  to 
identify  and  briefly  describe  the  R&D  work  conducted  at  DREV  in  these  critical  fields  that 
can  potentially  be  used  in  the  ASCACT  testbed. 

A  definition  is  first  given  of  the  mission  of  the  Data  Fusion  and  Resource 
Management  (DFRM)  research  group  at  DREV.  Mostly  based  on  the  work  conducted  by 
the  U.S.  Joint  Directors  of  Laboratories  Data  Fusion  Subpanel  (JDL/DFS),  various 
definitions  (i.e.,  data  fusion,  sensor  data  fusion,  situation  assessment,  threat  assessment 
and  resource  management)  derived  and  adopted  by  the  DFRM  group  are  also  given. 

The  many  R&D  results  of  the  activities  of  the  group  in  the  fields  of  MSDF,  STA 
and  RM  are  then  summarized  and  discussed  for  each  area  individually,  followed  by  some 
remarks  on  the  investigation  of  the  MS DF/ST A/RM  integration  issue.  The  discussion  of 
these  R&D  results  also  includes  some  references  to  current  work.  In  that  respect,  the 
conceptual  framework  study  and  the  collaborative  project  with  the  industry  represent  two 
new  activities,  each  one  deserving  a  separate  discussion.  Concerning  the  latter  activity, 
DREV  has  been  asked  to  integrate  its  work  in  MSDF,  STA  and  RM  to  allow  for  use  in  the 
ASCACT  testbed.  In  order  to  properly  conduct  this  integration,  DREV  is  currently 
assessing  forming  a  partnership  with  the  industry  for,  among  other  things,  the  development 
of  a  research  tool  (i.e.,  a  Simulated-Real-Time  Environment  (SRTE)).  This  tool  will  allow 
integrated  MSDF/STA/RM  research  to  be  performed,  thus  assessing  its  applicability  prior 
to  porting  to  the  ASCACT  testbed  (see  section  2.6.2.4). 

This  chapter  only  summarily  discusses  the  level  of  effort  required  to  port  the 
MSDF/STA/RM  technology  R&D  results  from  DREV's  work  to  ASCACT.  A  significant 
amount  of  work  still  remains  to  be  done  on  identifying  which  areas  of  DREV's  available 


FIGURE  6  -  Naval  command  and  control  conceptual  framework 
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results  and  proposed  work  should  be  implemented  and  further  investigated  within  the  initial 
version  of  the  ASCACT  testbed.  Recommendations  must  be  made  on  which  areas  best 
meet  ASCACT  requirements  for  implementation,  while  carefully  considering  the  risk  of 
advancing  with  undeveloped  theories  and  applications.  The  areas  of  study  should  possess 
high  potential  for  success  (i.e.,  follow  a  medium  risk  approach)  and  be  able  to  be  ported  to 
a  shipboard  application  for  operator  assessment  (although  the  timeline  for  this  port  remains 
to  be  defined).  As  much  as  possible  ideally,  consideration  should  also  be  given  to 
international  work  which  has  been  accomplished  in  these  fields  to  ensure  duplication  of 
effort  is  minimized  (i.e.,  do  other  countries  have  algorithms,  development  models  which 
could  be  used?).  These  considerations  mentioned  above  fall  beyond  the  scope  of  this 
document  and  will  be  addressed  in  a  subsequent  report  to  be  delivered  for  the  task. 

3.1  The  Data  Fusion  and  Resource  Management  Group 

The  R&D  activities  in  the  Data  Fusion  and  Resource  Management  Group  are 
primarily  concerned  with  tactical  C2  afloat.  Within  the  new  thrust  based  nomenclature 
adopted  by  the  CRAD  organization,  these  activities  are  covered  under  the  thrast  l.a. 
Integrated  Naval  Above  Water  Warfare  and  Shipboard  Command  and  Control.  More 
precisely,  the  activities  are  performed  under  project  l.a.5,  AWW  Command  and  Control. 
The  overall  objective  of  this  project  is  to  investigate  system  integration  concepts  for  the 
automation  of  command  and  control  processes  dealing  with  information  management  and 
decision-making  issues. 

In  that  context,  the  mission  of  the  DFRM  group  is  to  support  the  Navy  in  the 
development,  acquisition,  integration,  and  life  cycle  management  of  real-time  C2  systems 
for  target  tracking  and  identification,  situation  assessment,  threat  assessment  and  resource 
management.  This  is  done  through  R&D  in  the  areas  of  sensor  and  information  fusion, 
artificial  intelligence,  neural  networks,  intelligent  control,  system  architectures,  system 
integration,  distributed  and  high-performance  computing,  and  real-time  software 
development  methodologies,  and  their  application,  demonstration,  evaluation  and/or 
validation  in  experimental  and  advanced  prototype  CCISs. 

A  high-level  description  of  the  data  fusion  and  resource  management  C2  processes 
under  investigation  is  given  below.  The  responsible  scientists  in  each  area  are  also 
indicated. 


P435278.PDF  [Page:  49  of  128] 

UNCLASSIFIED 

33 

3.1.1  Data  Fusion  Definition 

Throughout  the  1980s  the  three  U.S.  military  services  pursued  the  development  of 
tactical  and  strategic  surveillance  systems  employing  data  fusion  and  supported  extensive 
research  in  the  areas  of  target  tracking,  target  identification,  algorithm  development  for 
correlation  (association)  and  classification,  and  the  application  of  intelligent  systems  to 
situation  assessment  (Ref.  6).  The  large  amount  of  fusion-related  work  in  this  period  raised 
some  concern  over  possible  duplication  of  effort.  As  a  result,  the  Joint  Directors  of  U.S. 
Department  of  Defense  (DoD)  Laboratories  (JDL)  convened  a  Data  Fusion  Subpanel  to  (1) 
survey  the  activities  across  all  services,  (2)  establish  a  forum  for  the  exchange  of  research 
and  technology,  and  (3)  develop  models,  terminology  and  a  taxonomy  of  the  areas  of 
research,  development  and  operational  systems. 

As  a  result  of  many  years  of  effort  to  establish  standardization  and  stability  in  the 
lexicon  of  data  fusion,  the  definition  of  many  terms  is  slowly  achieving  consensus  across 
the  diversified  application  community  (Ref.  7).  Problem-specific  nuances  and  shading  in 
these  definitions  remain  but  agreement  on  a  meaningful  subset  of  terms  does  seem  to  exist, 
providing  an  important  basis  for  communication  across  specialized  research  groups. 

Data  fusion  is  fundamentally  a  process  designed  to  manage  (i.e.,  organize,  combine 
and  interpret)  data  and  information,  obtained  from  a  variety  of  sources,  that  may  be 
required  at  any  time  by  operators  and  commanders  for  decision  support.  The  sources  of 
information  may  be  quite  diverse,  including  sensor  observations,  data  regarding  capability 
and  availability  of  targets,  topographic  and  environmental  data,  and  information  regarding 
doctrine  and  policy.  The  data  and  information  provided  by  these  various  sources  may 
contain  numbers  of  targets,  conflicting  reports,  cluttered  backgrounds,  degrees  of  error, 
deception,  and  ambiguities  about  events  or  behaviors. 

In  this  context,  Data  Fusion  (DF)  is  an  adaptive  information  process  that 
continuously  transforms  the  available  data  and  information  into  richer  information,  through 
continuous  refinement  of  hypotheses  or  inferences  about  real-world  events,  to  achieve 
refined  (and  potentially  optimal)  kinematic  and  identity  estimates  of  individual  objects,  and 
complete  and  timely  assessments  of  current  and  potential  future  situations  and  threats  (i.e., 
contextual  reasoning),  and  their  significance  in  the  context  of  operational  settings. 
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The  process  is  also  characterized  by  continuous  refinements  of  its  estimates  and 
assessments,  and  by  evaluation  of  the  need  for  additional  data  and  information  sources,  or 
modification  of  the  process  itself,  to  achieve  improved  results. 

3.1.2  Data  Fusion  Hierarchy 

The  process  of  data  fusion  may  be  viewed  as  a  multi-level  hierarchical  inference 
process  whose  ultimate  goal  is  to  assess  a  mission  situation  and  identify,  localize  and 
analyze  threats.  However,  not  every  data  fusion  application  is  responsible  for  all  of  these 
outputs.  Some  applications  are  only  concerned  with  the  position  and  identification  of 
objects.  Other  applications  are  primarily  oriented  towards  the  situation  and  how  it  is 
evolving.  Still  others  focus  on  the  threat  and  its  possible  impact  upon  achieving  mission 
objectives.  In  addition,  the  data  fusion  function  can  be  responsible  for  identifying  what 
information  is  most  needed  to  enhance  its  products  and  what  sources  are  most  likely  to 
deliver  this  information. 

Given  these  considerations,  a  complete  data  fusion  system  can  typically  be 
decomposed  into  four  levels: 

Level  1  -  Multi-Sensor  Data  Fusion  (MSDF); 

Level  2  -  Situation  Assessment  (SA); 

Level  3  -  Threat  Assessment  (TA);  and, 

Level  4  -  Process  Refinement  Through  Resource  Management  (RM). 

Each  succeeding  level  of  data  fusion  processing  deals  with  a  higher  level  of 
abstraction.  Level- 1  data  fusion  uses  mostly  numerical,  statistical  analysis  methods,  while 
levels-2,  3  and  4  data  fusion  use  mostly  symbolic,  Artificial  Intelligence  (AI)  methods. 
Note  that  resource  management  in  the  context  of  level-4  fusion  is  mainly  concerned  with 
the  information  gathering  process  refinement  (i.e.,  sensor  management).  The  overall 
domain  of  resource  management  also  encompasses  the  management  of  weapon  systems 
and  other  resources.  Figure  7  illustrates  the  overlap  between  the  data  fusion  and  resource 
management  domains. 
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FIGURE  7  -  Overlap  between  the  data  fusion  and  resource  management  domains 
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3. 1.2.1  Level  1  -  Multi-Sensor  Data  Fusion 

(Dr.  E.  Bosse  and  Mr.  J.  Roy) 

Multi-sensor  data  fusion  (MSDF)  is  concerned  solely  with  individual  objects,  first 
in  associating  the  sensor  outputs  with  specific  known  objects  or  using  them  to  initiate  new 
objects.  Level- 1  processing  uses  sensor  data  to  correctly  and  quickly  derive  the  best 
estimates  of  current  and  future  positions  for  each  hypothesized  object.  In  addition, 
inferences  as  to  the  identity  of  the  objects  and  key  attributes  of  the  objects  are  developed. 

Key  MSDF  functions  include:  data  alignment,  data  association/correlation, 
kinematic  data  fusion,  target  state  estimation,  target  kinematics  behavior  assessment,  target 
identity  information  fusion  and  track/cluster  management. 

3. 1.2.2  Level  2  -  Situation  Assessment 

(Mr.  R.  Carling) 

Based  on  incomplete  and  inaccurate  sets  of  data  and  information,  situation 
assessment  (SA)  is  devoted  to  the  continuous  inference  of  statements  about  the 
hypothesized  objects  provided  by  the  lower  level  data  fusion  function  in  order  to  derive  a 
coherent,  composite  tactical  picture  of  the  situation.  This  picture  must  be  described  in  terms 
of  groups  or  organizations  of  objects  so  that  enemy  intent  can  be  estimated  in  the  next 
higher  level  and  decisions  can  be  made  by  decision  makers  about  how  to  use  war  fighting 
assets. 


SA  deals  with  monitoring  and  short-term  or  immediate  situation  diagnosis.  Hence, 
SA  fits  hypothesized  objects  with  known  and  expected  organizations  and  events,  together 
within  the  constraints  of  terrain  and  enemy  tactics,  to  develop  a  description  or  interpretation 
of  the  current  relationships  among  these  objects  and  events  in  the  context  of  the  operational 
environment.  The  result  of  this  processing  is  a  determination  or  refinement  of  the 
battle/operational  situation. 

Based  on  the  situation  abstraction  products  and  information  from  technical  and 
doctrinal  databases,  SA  also  attempts  to  anticipate  future  events  over  a  short  time  horizon. 
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Key  SA  functions  include:  object  aggregation,  event/activity  aggregation,  contextual 
interpretation/fusion  and  multi-perspective  assessment. 

3. 1.2.3  Level  3  -  Threat  Assessment 

(Mr.  R.  Carling) 

Threat  assessment  (TA)  is  focused  at  the  details  necessary  for  decision  makers  to 
reach  conclusions  about  how  to  position  and  commit  the  friendly  forces.  It  can  be  viewed 
as  a  longer  term  diagnosis  function  to  determine  problems  in  the  current  situation  and 
identify  opportunities  for  taking  corrective  actions. 

By  coupling  the  products  of  situation  assessment  with  the  information  provided  by 
a  variety  of  technical  and  doctrinal  databases,  TA  develops  and  interprets  a  threat  oriented 
perspective  of  the  data  to  estimate  the  enemy  capabilities  and  lethality,  identify  threat 
opportunities  in  terms  of  the  ability  of  own  force  to  engage  the  enemy  effectively,  estimate 
enemy  intent  (i.e.,  provide  indications  and  warnings  of  enemy  intentions),  and  determine 
levels  of  risk  and  danger. 

Hence,  TA  uses  the  situation  picture  from  level  2  and  what  is  known  about  the 
enemy  doctrine  and  objectives  to  predict  the  strengths  and  vulnerabilities  for  the  threat 
forces  and  friendly  forces.  In  addition,  the  friendly  mission  and  specific  options  available 
to  the  decision  makers  are  tested  within  these  strengths  and  vulnerabilities  to  guide  decision 
making. 

Key  TA  functions  include:  enemy  forces  capability  estimation,  predict  enemy  intent, 
identify  threat  opportunities,  multi-perspective  assessment  and  offensive/defensive 
analysis. 


3. 1.2.4  Level  4  -  Process  Refinement  (Resource  Management) 

(Dr.  £.  Bosse,  Dr.  B.  Chalmers  and  Mr.  J.  Roy) 

Information  resource  management,  level  4  processing,  closes  the  loop  by  first 
examining  and  prioritizing  what  is  unknown  in  the  context  of  the  situation  and  threat  and 
then  developing  options  for  collecting  this  information  by  cueing  the  appropriate  sensors 
and  collection  sources. 
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3.1.3  Resource  Management  Definition 

(Dr.  B.  Chalmers ) 

Situation  and  threat  assessment,  together  with  command  team  interaction,  as 
required  or  as  response  time  permits,  is  used  to  drive  the  planning  and  decision  support 
functions  for  allocating  and  scheduling  the  use  of  critical  defence  resources  and 
coordinating  defence  actions  in  support  of  the  mission.  Determination  of  the  various 
options  for  use  of  the  resources  and  the  selection  of  the  best  course  of  action  in  a  given 
situation  is  known  as  Resource  Allocation.  Resource  Management  refers  to  the  continuous 
process  of  planning,  coordinating  and  directing  the  use  of  the  ship  or  force  resources  to 
counter  the  threat.  It  is  concerned  with  issues  of  both  command  and  control. 

3.2  Multi-Sensor  Data  Fusion 

The  overall  aim  of  the  MSDF  activity  at  DREV  (Refs.  1,  8-14)  is  to  analyze, 
develop  and  evaluate  advanced  techniques  to  automatically  produce  the  optimal  estimate  of 
the  position,  kinematic  behavior,  and  identification  of  all  objects  surrounding  a  single  ship, 
mainly  through  the  fusion  of  data  from  dissimilar  organic  sensors  (e.g.,  radar,  E-O,  ESM), 
while  including  inorganic  information  (e.g.,  data  coming  over  communication  links, 
intelligence  reports,  etc.).  The  use  of  the  latter  type  of  information  is  directed  towards  the 
potential  enhancement  of  the  performance  of  the  different  sensor  data  fusion  sub-processes. 
The  specific  aim  of  the  MSDF  project  is  to  demonstrate  cooperative,  synergistic,  and 
efficient  utilization  of  all  of  the  CPF  AWW  sensor  elements. 

Figure  8  emphasizes  the  typical  inputs  to  the  MSDF  process.  Contacts  (or  raw 
measurements)  and  tracks  from  multiple  dissimilar  sensors  are  processed  to  form  the 
tactical  picture  in  the  local  area  surrounding  a  single  ship  platform.  This  sensor  data 
information  can  be  generated  locally,  or  it  may  come  from  other  platforms  via 
communication  data  links.  Typically,  modern  sensors  process  their  own  raw  data  to 
produce  local  tracks.  However,  depending  on  the  selected  fusion  architecture,  it  is  assumed 
that  one  also  has  access  to  the  raw  sensor  reports. 

Figure  9  is  a  decomposition  of  the  MSDF  process  into  its  constituent  sub¬ 
processes.  Those  that  are  typically  identified  in  the  literature  as  necessary  to  perform  the 
level- 1  MSDF  function  are  data  alignment,  data  association  or  correlation,  kinematic  data 
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FIGURE  8  -  Typical  data  inputs  to  an  MSDF  function 
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FIGURE  9  -  Functional  decomposition  of  the  MSDF  process 
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fusion,  target  state  estimation,  target  kinematics  behavior  assessment,  target  identity 
information  fusion  and  track  management.  Each  sub-process  identified  in  Fig.  9  is  being 
analyzed  and  studied  under  the  project  in  terms  of  the  specific  algorithms  and  techniques 
applicable  to  each  process.  Figure  10  is  an  overview  of  the  principal  issues  that  have  been 
investigated  so  far  with  respect  to  the  MSDF  sub-processes  illustrated  in  Fig.  9. 

The  partitioning  of  the  sub-processes  is  sometimes  arbitrary  and  depends  on  a 
specific  architecture  for  physical  implementation.  Therefore,  the  flow  of  information  from 
one  process  to  the  other  is  also  being  studied  under  the  project  so  that  various 
configurations  or  types  of  architecture,  that  make  use  of  basic  algorithms  for  each  sub¬ 
process,  are  investigated  as  options  to  implement  the  overall  MSDF  function. 

3.2.1  MSDF  Results 

Up  to  now,  a  large  portion  of  the  research  conducted  by  the  Data  Fusion  and 
Resource  Management  Group  in  the  MSDF  domain  has  been  done  through  collaboration 
with  universities  and  Canadian  industry.  Results  have  been  documented  in  several  reports 
(Refs.  15-42).  The  C2  Division  has  also  been  strongly  involved  as  scientific  advisor  for 
two  DIRP  projects  undertaken  by  the  Canadian  industry  and  related  to  sensor  data  fusion. 
Again,  results  have  been  documented  in  several  reports  and  papers  (Refs.  43-49).  The 
following  paragraphs  give,  with  respect  to  each  of  the  major  MSDF  sub-processes,  a  very 
brief  overview  of  the  research  issues  that  were  addressed.  Details,  and  discussions  of  other 
aspects  not  covered  here,  can  be  found  in  the  references. 

The  term  "MSDF  architecture"  is  used  to  indicate,  based  on  the  level  at  which  the 
sensor  data  are  fused  (i.e.,  signal,  contact  or  track  level),  the  general  method  (or 
philosophy)  used  to  combine  the  sensor  data  into  global  tracks  within  an  MSDF  function. 
Figure  1 1  illustrates  on  a  single  diagram  the  usual  definition  of  three  types  of  MSDF 
architecture  for  two  generic  sensors.  The  MSDF  architecture  is  an  important  issue  since  the 
fusion  benefits  are  different  depending  on  the  way  the  sensor  data  are  combined.  Various 
theoretical  analyses  on  different  types  of  multiple  sensor  data  association  and  fusion 
architecture  have  been  performed  under  the  MSDF  project  at  DREV  (Refs.  18-19,  27,  31, 
33,  38).  Comparative  studies  (i.e.,  advantages  vs.  disadvantages,  trade-offs)  have  been 
conducted  for  the  sensor-level  method  vs.  the  central-level  approach  in  terms  of 
computational,  data  base,  and  communication  requirements.  The  possibility  of  using  a 
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mixture  of  these  two  types  of  architecture  to  form  a  hybrid  (or  combined)  tracking  structure 
has  also  been  investigated. 

The  effects  of  misalignment  on  the  performance  of  the  data  association  and  fusion 
techniques  have  been  studied  under  the  MSDF  project  at  DREV.  Both  spatial  and  time 
alignment  problems  have  been  addressed.  Solutions  to  misalignment  have  been 
investigated,  based  on  filtering  theory  (Refs.  18,  27,  31). 

Target  state  estimation  is  a  statistical  process  used  to  infer,  in  some  optimal  fashion, 
the  state  of  a  dynamic  target  based  on  collected  noisy  sensor  measurements.  The  purpose  of 
the  kinematic  behavior  assessment  MSDF  sub-process  is  to  support  and  complement  the 
target  state  estimation  sub-process  during  target  maneuvers.  Both  processes  together  are 
generally  referred  to  more  simply  as  the  target  tracking  process  per  se.  Multiple  issues 
involved  in  addressing  the  problem  of  high  precision  tracking  of  a  target  have  been  studied 
in  depth.  Indeed,  the  overall  Kalman  filtering  domain  as  applied  to  target  tracking  has  been 
surveyed  in  order  to  sum  up  the  state-of-the-art  in  target  state  estimation  based  on  classical 
estimation  theory.  Among  the  issues  studied,  basic  Kalman  filters  (i.e.,  covariance  vs. 
information  type  filters,  coupled  vs.  decoupled  filters,  extended  Kalman  filter,  etc.), 
adaptive  Kalman  filtering  structures  for  maneuvering  targets  (e.g.,  the  Interacting  Multiple- 
Model  (IMM)  algorithm,  etc.),  target  state  models  (e.g.,  two-state  filters,  three-state  filters, 

■  etc.),  assumed  target  process  noise  (e.g.,  white  noise  acceleration,  colored  noise,  etc.), 
target  maneuver  detectors  (e.g.,  fading  sum  or  sliding  sum,  etc.),  filter  initialization 
concepts,  the  effect  of  measurement  dropout  (i.e.,  non-unity  probability  of  detection),  and 
the  selection  of  the  filter  parameter  values  for  performance  optimization  based  on  physical 
considerations  have  been  addressed  (Refs.  18,  30,  32-42). 

The  fundamental  problem  in  a  multi-sensor  multi-target  scenario  lies  in  resolving 
the  ambiguous  measurement  association  decisions.  It  is  difficult,  when  tracking  multiple 
targets  in  a  cluttered  environment,  to  select  among  many  returns  the  correct  or  true  return 
from  a  given  target  to  be  used  within  the  tracking  algorithm  for  track  updating.  Various  data 
association  approaches  proposed  in  the  MSDF  literature  (e.g.,  ellipsoidal  gating,  Nearest- 
Neighbor  (NN),  Multiple  Hypothesis  Tracking  (MHT),  Joint  Probabilistic  Data 
Association  Filter  (JPDAF),  etc.)  have  been  reviewed  and  described  in  depth  under  the 
MSDF  project  at  DREV  (Refs.  18-19,  26-29,  31).  The  extension  of  these  basic  algorithms 
and  techniques  has  also  been  studied  in  order  to  use  them  within  a  multiple  sensor 
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configuration.  Many  other  aspects  of  the  sensor  data  correlation  process  have  also  been 
investigated.  In  particular,  how  to  deal  with  the  measurement  vector  (or  state  vector  if  one 
considers  tracks)  dissimilarities  between  two  or  more  sensors  (e.g.,  different  dimension, 
dissimilar  type  of  information,  etc.)  has  been  considered.  This  issue  arises,  for  example, 
when  one  tries  to  associate  active  radar  data  (including  range  information)  with  passive  IR 
sensor  data  (no  range  information).  The  resolution  differences  between  sensors  (e.g.,  the 
IR  sensor  resolves  multiple  targets  when  a  radar  makes  a  single  target  declaration),  the 
potential  problem  when  multiple  ESM  tracks  (multiple  emitters)  are  established  from  a 
single  target  that  is  also  seen  by  another  sensor,  the  association  of  IR  and  radar  data  with 
ESM  data  when  the  latter  sensor  has  only  a  relatively  inaccurate  angle  in  common  with  the 
two  others,  are  other  issues  that  have  been  addressed. 

Vastly  differing  methodologies  have  been  successfully  applied  to  the  generic  sensor 
fusion  problem.  A  review  of  proposed  theoretical  fusion  techniques  in  the  MSDF  literature, 
and  the  practical  implications  of  each,  has  been  conducted  (Refs.  11,  15-16,  18-19,  24-25, 
27,  31,  33,  38).  The  majority  of  generally  applicable  techniques  appeal  to  probability 
theory  to  achieve  descriptions  of  the  sensor's  abilities  (qualitative  models)  with  appropriate 
statistically  based  fusion  schemes.  These  probabilistic  approaches  can  be  further  separated 
into  techniques  utilizing  statistical  decision  theory,  maximum  likelihood  techniques,  while 
the  majority  incorporate  linear  Bayesian  estimation  techniques. 

The  target  identification  aspect  has  also  been  considered  in  order  to  produce  the 
complete  tactical  picture  required  by  the  subsequent  C2  processes.  Two  approaches  have 
been  studied  in  parallel  to  investigate  and  evaluate  fusion  techniques  capable  of  combining 
uncertain  information  in  the  form  of  identity  information.  The  first  approach  deals  with 
attribute  information  (Refs.  15-16)  while  the  second  one  focuses  on  identity  declarations 
(Ref.  11). 

In  the  first  study,  attribute  information  obtained  from  various  sensors  is  compared 
to  a  Platform  Data  Base  containing  all  the  possible  identity  values  that  the  potential  target 
may  take.  Each  record  of  this  data  base  contains  information  related  to  the  measured  sensor 
attributes.  Therefore  each  sensor's  attribute  information  is  translated  into  a  subset  of  the 
Platform  Data  Base  and  a  confidence  level  for  each  subset  is  then  computed.  The  subsets, 
called  propositions,  are  then  combined  using  Dempster-Shafer  Evidential  theory.  However, 
as  various  propositions  are  combined  over  time,  the  Dempster-Shafer  combination  rules 
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have  a  tendency  to  generate  more  and  more  propositions  which  in  turn  must  be  combined 
with  new  propositions.  This  problem  is  known  to  increase  exponentially.  The  algorithm 
proposed  rigorously  controls  the  amount  of  input  and  output  propositions  by  pruning  the 
"unessential"  propositions  and  selecting  the  "best"  identity  propositions  by  applying 
selection  criteria.  Therefore  a  finite  number  of  candidate  identifications  is  retained.  This 
technique  is  called  the  truncated  version  of  the  Dempster-Shafer  Evidential  approach  and 
has  been  applied  to  fuse  attributes  from  the  sensor  suite  of  a  frigate  size  AWW  ship.  The 
sensor  suite  considered  consists  of  long  and  medium  range  radars,  IRST,  IFF  and  ESM 
sensors. 

In  the  second  study,  the  emphasis  is  given  to  the  idea  that  sensors  are  self-contained 
and  capable  of  estimating  identity  declarations.  Such  a  declaration  specifies  the  detected 
object;  it  can  consist  of  a  general  classification  of  which  the  observed  object  is  a  member 
(surface  combatant),  a  specific  type  of  ship  (frigate),  a  specific  class  (City  Class)  or  a 
unique  identity  (Ville  de  Quebec).  Identity  declaration  can  also  include  information 
concerning  the  threat  designation  of  an  object:  pending,  unknown,  assumed  friend, 
suspect,  friend,  neutral  or  hostile.  The  study  also  assumes  that  identity  declarations  are 
probabilistic  in  nature  such  that  each  declaration  is  characterized  by  a  confidence  value  and 
that  the  declarations  are  independent. 

The  MSDF  environment  poses  unique  challenges  to  the  mandate  of  the  track 
manager  and  thus  motivates  the  development  of  advanced  management  schemes.  In 
particular,  the  MSDF  function  must  exploit  the  complementary  characteristics  among  the 
multiple  sensor  reports  in  order  to  perform  track  initiation  and  maintenance  better.  Track 
management  concepts  have  been  investigated  under  the  MSDF  project  at  DREV.  Results 
have  been  documented  in  several  reports  (Refs.  18-19,  26-29). 

3.2.2  The  CASE_ATTI  Tool 

The  CASE_ATTI  (Concept  Analysis  and  Simulation  Environment  for  Automatic 
Target  Tracking  and  Identification)  system  is  a  highly  modular,  structured  and  flexible 
simulation  environment  providing  the  algorithm-level  test  and  replacement  capability 
required  to  study  and  compare  the  technical  feasibility,  applicability  and  performance  of 
advanced,  state-of-the-art  MSDF  techniques  (Ref.  1). 
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Figure  12  illustrates  the  global  structure  of  the  CASE_ATTI  system.  The  sensor 
module  is  responsible  for  providing  realistic  measurement  data  to  the  tracking  algorithms. 
Given  a  user-defined  scenario,  it  generates  true  target  positions  and  measured  target 
positions,  which  are  subsequently  made  available  to  the  tracking  module.  Currently,  the 
module  supports  radar  and  IRST  sensor  simulations.  More  specifically,  the  CPF  radars 
currently  supported  by  the  CASE_ATTI  sensor  module  are  the  SG-150  Sea  Giraffe  and  the 
AN/SPS-49  long  range  radar.  An  adaptation  of  the  CASE_ATTI  radar  model  is  ongoing  to 
also  support  the  CPF  fire  control  system  STIR  radar.  A  contract  is  about  to  begin  for  the 
integration  of  ESM  data  into  the  sensor  module.  This  ESM  simulation  capability  will  be 
representative  of  CANEWS. 

The  current  tracking  module  in  CASE_ATTI  supports  a  wide  variety  of  tracker 
architecture  types,  varying  from  a  simple  single  sensor  tracker  to  an  arbitrarily  complex 
hierarchical  multiple  sensor  topology.  Its  design  has  the  capability  of  simulating  a  sensor- 
level,  central-level  or  hybrid  tracking  architecture  as  required.  Finally,  the  data  extraction, 
visualization  and  analysis  module  comprise  a  set  of  computer  tools  implemented  in 
CASE_ATTI  to  help  the  MSDF  designer  in  his  assessment  of  the  performance  of  the 
algorithms  and  techniques. 

It  is  believed  that  large  portions  of  CASE_ATTI  could  become  an  integral  part  of 
the  ASCACT  testbed.  The  sensor  module  (i.e.,  the  sensor  simulations,  the  target  container, 
etc.)  could  be  modified  to  act  as  a  stimulator  for  the  ASCACT  testbed.  This  would 
necessitate  that  feedback  information  be  incorporated  and  used  in  the  sensor  module  in 
order  to  close  the  loop  with  MSDF,  STA  and  RM,  and  accommodate  the  simulation  of 
highly  dynamic  and  interactive  scenarios.  The  tracking  module  could  be  used  to  create  any 
MSDF  architecture.  The  performance  evaluation  process  could  be  used  to  evaluate  the 
ability  of  the  MSDF  system  to  generate  measured  and  estimated  tactical  pictures  that 
accurately  reproduce  the  ground  truth  tactical  picture. 

However,  before  any  of  these  possibilities  is  further  developed,  it  is  necessary  to 
consider  real-time  aspects  as  required  for  ASCACT.  In  that  respect,  most  of  the  sensor 
module  could  probably  be  used  as  it  is.  However,  the  tracking  module  encompasses  a  lot 
of  overhead  code,  the  purpose  of  which  is  to  provide  the  required  flexibility  to  explore 
different  MSDF  architectures.  For  the  ASCACT  testbed,  it  is  recommended  that  a  specific 
MSDF  architecture  be  first  selected,  and  then  the  appropriate  MSDF  code  be  extracted  from 
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CASE_ATTI  to  be  reused  in  the  testbed.  Further  analysis  is  however  required  to  confirm 
the  feasibility  of  this  approach. 

3.2.3  Ongoing  R&D  Work  Performed  Under  Tasking  by  DMSS  6 

Most  of  the  current  research  in  MSDF  is  dedicated  to  the  development  and 
application  of  new  techniques,  but  little  has  been  performed  to  determine  how  well  such 
methods  apply  to  a  practical  system.  The  CPF  is  a  very  interesting  platform  for  MSDF 
application.  Reference  1  discusses  an  ongoing  study  making  use  of  the  CASE_ATTI 
system  to  support  the  development  of  MSDF  concepts  that  could  apply  to  the  current  CPF 
sensor  suite,  as  well  as  its  anticipated  upgrades  (i.e.,  MFR,  IRST,  CANEWS  2),  in  order 
to  improve  its  AWW  performance  against  the  predicted  future  threat.  The  study  is 
sponsored  by  DMSS  6  through  a  task  entitled:  "Development  of  Sensor  Integration 
Techniques  for  CPF  AWW  Sensor  Suite  Configurations".  It  aims  to  identify  and  develop 
techniques  for  combining  Radars/EO/ESM  data,  and  to  evaluate  the  real  benefits  of  the 
combination.  Two  major  aspects  need  to  be  addressed  for  this  application:  first,  the 
representation  of  the  actual  CPF  sensor  suite  to  establish  its  baseline  performance,  and 
second,  the  quantification  of  the  performance  improvements  gained  when  using  an 
upgraded  sensor  suite  combined  with  advanced  MSDF  concepts. 

The  definition  of  the  CPF  baseline  performance  for  this  study  comprises  two  related 
aspects.  Firstly,  the  performance  of  the  current  sensors  operating  in  a  stand  alone  mode  is 
evaluated.  Secondly,  the  global  performance  of  the  complete  sensor  suite  is  evaluated 
taking  into  account  the  limited  integration  that  is  performed  within  the  current  CPF 
Command  and  Control  System  (CCS).  In  both  cases,  it  is  assumed  that  the  sensors  are 
performing  in  accordance  with  their  specifications.  It  is  out  of  the  scope  of  this  project  to 
verify  if  the  sensors  meet  their  specifications. 

The  current  AWW  sensor  suite  of  the  CPF  comprises  the  SPS-49  long  range  2-D 
radar,  the  Sea  Giraffe  medium  range  2-D  radar,  the  CANEWS  ESM  and  the  Separate  Track 
and  Illumination  Radar  (STIR).  The  surveillance  radar  models  used  in  this  study  allow  the 
generation  of  measurements,  as  well  as  a  representation  of  the  tracking  performed  inside 
the  sensors.  As  a  result,  the  simulated  data  are  very  close  to  the  outputs  of  the  SPS-49  and 
Sea  Giraffe.  This  represents  an  original  novelty  of  our  simulation  environment. 
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The  baseline  performance  will  be  evaluated  against  the  predicted  future  threat.  More 
precisely,  all  performance  evaluations  will  be  against  the  AWW  mission  and  threat 
requirements,  including  maneuvering  targets  and  if  possible  ECM  conditions,  which  are 
currently  being  specified  by  the  Canadian  Navy.  The  environmental  scenarios  to  be  used 
will  be  those  developed  by  DREV  for  the  NATO  Anti  Air  Warfare  System  (NAAWS) 
program. 

The  Canadian  Navy  is  planning  to  upgrade  the  CPF  sensor  suite.  However,  the 
development  and/or  acquisition  of  advanced  AWW  sensors,  although  necessary,  may  not 
be  sufficient  for  providing  the  required  protection  for  ships  against  the  anticipated  future 
threats.  The  simple  interfacing  of  these  components  is  not  enough  because  such 
independent  AWW  elements  are  seldom  used  in  a  coordinated  manner,  which  typically 
leads  to  a  confusing  and  time-late  decision  environment  for  the  ship's  commander.  Hence, 
the  effectiveness  of  the  AWW  system  is  not  completely  determined  by  the  capabilities  of  the 
AWW  sensor  suite  alone,  but  also  by  the  effectiveness  of  the  system  integration  which 
must  focus  on  cooperative,  synergistic,  and  efficient  utilization  of  all  of  the  AWW  sensors. 

In  that  context,  an  incremental  approach  has  been  chosen  to  demonstrate  how  the 
performance  of  the  CPF  sensor  suite  can  be  improved  using  an  upgraded  sensor  suite 
combined  with  advanced  MSDF  concepts.  The  idea  is  to  compare  alternative  methods 
against  a  common  problem  and  to  evaluate  the  results  with  respect  to  the  baseline 
performance.  The  first  step  is  to  allow  minor  modifications  to  the  existing  system  such  that 
the  current  tracking  algorithms  for  each  sensor  taken  individually  can  be  improved  with 
advanced  techniques,  and  sensor  data  fusion  can  be  used  within  the  CCS.  This  is 
accomplished  within  the  CASE_ATTI  system.  CASE_ATTI  allows  the  possibility  of  trying 
all  kinds  of  tracking  algorithms  as  well  as  assessing  the  performance  of  various  types  of 
fusion  architecture.  Any  resulting  performance  improvements  with  respect  to  the  baseline 
performance  will  be  quantified. 

The  second  step  is  to  add  an  Infrared  Search  and  Track  (IRST)  simulation  to  the 
current  representation  of  the  CPF  sensor  suite.  The  required  MSDF  techniques  and 
algorithms  to  support  this  addition  to  the  sensor  suite  will  be  identified  and  developed.  The 
performance  obtained  through  MSDF  for  the  modified  sensor  suite  will  be  evaluated  and 
any  resulting  improvements  will  be  quantified. 
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The  last  step  is  to  further  modify  the  current  CPF  sensor  suite  by  replacing  the 
STIR  and  the  Sea  Giraffe  simulations  with  a  Multi-Function  Radar  (MFR)  model,  and  by 
upgrading  the  CANEWS  ESM  simulation.  The  MSDF  algorithms  and  techniques  required 
for  the  integration  of  this  upgraded  sensor  suite  will  be  identified  and  developed.  Again, 
any  resulting  performance  improvements  will  be  quantified. 

3.2.4  Porting  of  the  MSDF  Results  in  ASCACT 

As  presented  in  section  3.2  above,  a  lot  of  work  on  the  use  of  the  MSDF 
technology  in  a  naval  context  has  been  conducted  by  DREV.  These  research  activities  have 
resulted  in  a  major  improvement  of  the  knowledge  base  at  DREV  in  the  field  of  MSDF.  As 
a  result  of  this  work,  DREV  has  acquired  the  capacity  to  advise  the  Forces  in  the  selection 
of  integrated  surveillance  and  tracking  systems  suitable  to  fulfill  their  requirements,  and,  in 
the  optimization  of  the  operation  of  these  systems  to  obtain  the  best  performance.  What 
remains  to  be  done  for  the  ASCACT  project  is  to  provide  an  explicit  definition  of  the 
MSDF  process  required  for  the  CPF  (or  at  least  a  specification  of  the  configuration  that  will 
first  be  used  in  the  initial  MSDF/STA/RM  baseline  application  implementation  in  the 
ASCACT  testbed)  by  selecting  and  combining  appropriate  candidate  techniques  or  issues 
previously  studied  by  DREV.  This  selection  of  MSDF  algorithms  among  those  investigated 
at  DREV  must  also  consider  their  implementation  in  real-time  to  be  suitable  for  the 
ASCACT  testbed.  It  is  believed  that  the  level  of  effort  to  achieve  this  goal  is  not  very  high 
and  that  a  recommendation  (including  a  detailed  specification)  can  be  developed  in  the 
framework  and  timeline  of  the  ASCACT  Integration  Working  Group  activities. 

3.3  Situation  and  Threat  Assessment 

The  purpose  of  this  section  is  to  summarize  all  the  important  research  activities  in 
Threat  Evaluation  and  Weapon  Assignment  (TEW A)  and  Naval  Situation  Assessment  that 
have  taken  place  at  DREV  over  the  past  five  years  and  indicate  their  potential  connection 
with  the  ASCACT  project.  There  were  five  major  research  activities  in  this  area: 

(1)  the  building  of  a  knowledge-based  Threat  Evaluation  and  Weapon 
Assignment  process  for  a  single  stationary  AAW  destroyer  attacked  by 
anti-ship  missiles. 
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(2)  the  building  of  a  multiple  ship  AAW  Simulator  for  studying  the 
decision  making  of  the  knowledge-based  Threat  Evaluation  and 
Weapon  Assignment  process  described  in  (1)  for  each  ship  that  is 
attacked  by  anti-ship  missiles. 

(3)  the  building  of  a  TEW  A  resource  loading  study  for  studying  the 
messages  sent  between  a  TRUMPlike  ship’s  sensors  and  weapons  and 
the  Battle  Management  Functions  residing  on  its  command  and  control 
computers. 

(4)  the  design  of  real-time  knowledge-based  systems  and  fuzzy  expert 
systems  for  naval  Situation  and  Threat  Assessment  (STA)  where 
multiple  air  platforms  (aircraft,  anti-ship  missiles)  are  attacking 
warships,  or  aircraft  and  helicopters  are  conducting  various  operations 
(not  necessarily  hostile)  in  the  warships’  airspace. 

(5)  the  implementation  of  a  real-time  knowledge -based  system  for  naval 
STA  using  the  MUSE  shell  executing  on  a  single  processor 
workstation. 

Section  3.3  describes  the  work  done  in  each  of  these  projects. 

3.3.1  Knowledge-Based  TEWA 

A  detailed  description  of  the  knowledge-based  TEWA  and  the  sensor  and  weapon 
models  interacting  with  it  can  be  found  in  Refs.  50-54. 

A  knowledge-based  threat  evaluation  and  weapon  assignment  (TEWA)  process  has 
been  built  in  SMALLTALK  80/HUMBLE  by  Thomson  CSF  Systems  Canada.  The 
knowledge-based  system  consists  of  four  knowledge  bases  comprising  110  rules 
altogether.  This  knowledge -based  system  was  initially  developed  for  a  single  stationary 
AAW  destroyer  attacked  by  radar  guided  anti-ship  missiles.  The  knowledge-based  system 
consisted  of  two  parts:  a  TEWA  target  track  generator  and  the  TEWA  simulator  containing 
the  actual  knowledge-based  system.  Both  of  these  two  parts  were  coded  in  SMALLTALK 
80,  while  the  knowledge-based  system  was  built  from  the  HUMBLE  shell.  In  the  rrEWA 
simulator,  there  are  basic  models  for  the  surveillance  radars,  fire-control  radars,  electronic 
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support  measures  (ESM)  and  infrared  search  and  detect  devices.  In  addition,  there  is  a 
sensor  data  fusion  process  that  is  modeled  using  sensor  level  fusion.  This  means  that  tracks 
are  formed  for  the  air  threats  at  each  sensor  node  after  going  through  the  operations  of  data 
association  and  track  correlation.  Finally,  tracks  from  various  sensors  are  fused  together 
using  minimum  variance  fusion.  Various  kinds  of  air  threats  :  high  diver,  shallow  diver, 
sea  skimmer  and  hybrid  diver  are  completely  simulated  from  their  launch  point  until  they 
reach  their  impact  point  with  the  ship.  The  knowledge-based  system  performs  a  threat 
evaluation  for  each  track  coming  from  the  sensor  data  fusion  process  and  this  is  followed 
by  the  execution  of  a  resource  allocation  plan  assigning  as  many  weapons  as  possible  to  all 
the  ranked  tracks.  The  sensor  fusion  and  resource  allocation  parts  of  the  KBS  TEWA  were 
developed  five  years  ago  when  integrated  work  between  scientists  studying  MSDF,  STA 
and  RM  was  less  of  a  concern. 

The  design  of  the  knowledge-based  system  for  the  single,  stationary  AAW 
destroyer  is  given  in  Fig.  13.  It  consists  of  knowledge  bases,  and  a  ranking  of  reactions 
function.  The  knowledge  bases  are  called  respectively:  Target  Evaluation,  Result 
Evaluation,  Force  Resources  Evaluation  and  Candidate  Reaction  Evaluation.  The  Target 
Evaluation  knowledge  base  consists  of  rules  for  threat  identity,  threat  radar  mode,  threat 
engagement  status  and  threat  kinematic  parameters.  The  other  rules  are  rules  for  combining 
the  threat  identity  characteristics,  the  threat  kinematic  values,  the  radar  mode  characteristics 
and  the  engagement  status  characteristics.  They  combine  the  above  four  characteristics  to 
produce  a  value  of  threat  level.  There  is  a  Result  Evaluation  knowledge  base  that  does  kill 
assessment  for  each  kind  of  hardkill  and  softkill  weapon  system  on  the  ship.  There  is  also  a 
Force  Resources  Evaluation  knowledge  base  which  monitors  the  availability  and  stock  level 
of  weapons  systems  before  assignment.  There  is  a  fourth  knowledge  base  which  assesses 
whether  candidate  hardkill  or  softkill  weapons  can  be  assigned  to  threats. 

Results  from  the  knowledge-based  TEWA  are  shown  in  Refs.  55-57.  An  alternative 
approach  using  a  conventional  TEWA  is  described  in  Ref.  58,  while  additional  work  to 
close  the  TEWA  loop  for  the  chaff  reaction  is  described  in  Ref.  59. 

3.3.2  The  Anti-Air  Warfare  Simulator 

The  twenty  modeled  entities  of  the  AAW  Simulator  were  designed  according  to  the 
specifications  of  Refs.  2-4,  coded  in  SMALLTALK  80  and  subjected  to  acceptance  tests. 
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FIGURE  13  -  An  architecture  for  the  knowledge-based  system 
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Since  the  results  obtained  from  the  first  coding  of  the  AAW  simulator  were  not  entirely 
correct,  the  functionality  of  the  modeled  entities  was  recently  revised  by  Thomson  CSF 
Systems  Canada  and  the  entities  have  been  coded  again.  The  following  is  a  list  of  modeled 
entities  of  the  AAW  Simulator  which  does  not  include  the  TEWA  modeled  entity. 

•  Surveillance  Radar  Model 

•  Fire-Control  Radar  Model 

•  Electronic  Support  Measures  System 

•  Infrared  Search  and  Track  System 

•  Surface-to-Air  Missile  Model 

•  Threat  Model 

•  Chaff  and  Chaff  Controller  Models 

•  Naval  Gun  and  CIWS  models 

•  Tracking  Processor 

•  Continuous  Wave  Illuminator 

•  Sensor  Data  Fusion  Processor(SDFP) 

•  Fire-Control  Processor 

•  Missile  Launch  Controller  (MLC) 

•  Jammer 

•  Sensor  Management  Processor 

•  Internal  Communication  System 

•  External  Communication  System 

•  Force  Resource  Data  Fusion  Processor 

•  Seaborne  Platform 

The  knowledge-based  TEWA  system  discussed  in  section  3.3.1  that  was  developed 
for  a  single  stationary  AAW  destroyer  has  been  modified  in  order  to  accommodate  hardkill 
or  softkill  reactions  deployed  from  a  maneuverable  ship.  The  AAW  Simulator  is  being 
developed  for  several  warships  which  can  maneuver  when  attacked  by  anti-ship  missiles. 
Ship  rotation  is  used  to  support  hardkill  reactions.  More  specifically,  ship  rotation  may 
occur  in  order  to  unmask  a  fire-control  radar  or  naval  gun  that  is  in  a  blind  zone.  Ship 
rotation  is  also  employed  to  use  the  chaff  system  more  effectively  against  anti-ship  missile 
threats.  Although  the  generic  sensor  and  weapon  models  of  the  AAW  Simulator  are 
accurate,  no  use  is  made  at  the  moment  of  doctrine  to  specify  the  interference  caused  by  the 
use  of  operational  hardkill  and  softkill  systems.  Currently,  the  knowledge-based  TEWA  of 
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the  AAW  simulator  will  allocate  a  rotation  before  deployment  of  hardkill  and/or  softkill 
weapons.  These  rotations  may  interfere  with  each  other  in  the  sense  that  a  hardkill  rotation 
is  in  the  starboard  direction  while  a  softkill  rotation  is  in  the  port  direction.  The  AAW 
simulator  indicates  each  occurrence  of  hardkill/softkill  interference  and  the  effect  of  this 
interference  on  the  number  of  anti-ship  missiles  destroyed  or  decoyed.  The  only  other  kind 
of  interference  considered  so  far  is  spatial  interference  caused  by  a  chaff  cloud  obscuring  a 
fire-control  radar  line  of  sight. 

The  AAW  Simulator  simulates  the  launching  of  anti-ship  missiles  from  aircraft  at 
long  range  (200  km)  or  medium  range  (70  km).  The  types  of  anti-ship  missile  simulated  are 
high  divers,  shallow  divers  or  sea-skimmers.  Threats  have  radar,  infrared  or  anti-radiation 
missile  seeker  heads.  The  AAW  Simulator  simulates  the  acquisition  and  tracking(lock-on) 
modes  of  the  radar  anti-ship  missiles.  During  acquisition  mode,  the  radar  seeker  head 
calculates  a  signal-to-noise  ratio  for  each  target  within  its  field  of  view  (a  ship  of  the 
convoy,  chaff  cloud).  The  seeker  head  chooses  the  target  with  the  highest  signal-to-noise 
ratio  and  remains  locked  onto  it  until  shot  down  by  a  surface-to-air  missile  or  the  seeker 
head  loses  the  missile  radar  signal  because  the  signal-to-noise  ratio  suddenly  becomes 
small.  The  infrared  seeker  head  modeled  is  the  non  imaging  type  of  IR  seeker  head  (reticule 
seeker  head).  The  anti-radiation  seeker  head  model  is  similar  to  the  radar  seeker  head 
model. 


In  the  single  ship  scenarios  of  the  AAW  Simulator,  a  CPFlike  ship  detects  the  anti¬ 
ship  missiles  at  long  range  and  the  tracking  processor  generates  radar  tracks  of  the  threats. 
As  soon  as  the  tracks  are  within  range  of  the  ship's  fire-control  radar,  tracking  of  selected 
targets  begins  as  dictated  by  the  threat  evaluation  function.  Since  the  tracks  are  extremely 
fast  and  take  no  evasive  action  when  tracked  by  a  fire-control  radar,  it  is  concluded  that 
they  are  not  civilian  or  friendly  aircraft.  The  knowledge-based  TEWA  then  decides  whether 
rotation  can  take  place  before  the  threats  reach  the  ship.  If  so,  rotation  takes  place  so  that 
the  ship  can  be  in  a  position  where  it  can  use  all  hardkill  weapons  against  the  threats.  The 
output  from  the  AAW  Simulator  is  a  series  of  assignments  of  hardkill  and  softkill  weapon 
systems  against  the  threats  attacking  the  ship  which  are  designated  by  the  threat  evaluation 
function.  If  chaff  is  deployed,  the  ship  may  have  to  make  a  further  small  rotation  to  use 
chaff  more  effectively. 
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In  the  multiple  ship  scenarios,  a  TRUMPlike  ship  is  the  anti-air  warfare  commander 
(AAWC)  of  a  group  of  four  ships  including  two  CPFlike  ships.  Anti-ship  missile  threats 
with  the  same  kind  of  seeker  heads  as  in  the  single  ship  case  are  targeted  from  medium 
range  at  each  of  the  four  ships.  The  ships  reason  about  these  radar  air  tracks  as  before  and 
take  up  the  best  position  for  use  of  hardkill  weapons  against  the  threats.  The  output  from 
the  AAW  Simulator  is  a  series  of  assignments  of  hardkill  and  softkill  weapon  systems  for 
each  ship  of  the  convoy  against  the  threats  designated  by  the  ship's  threat  evaluation 
function.  The  AAW  Simulator  is  used  to  study  issues  affecting  the  design  of  a  knowledge- 
based  TEWA  in  a  convoy  of  ships,  e.g.,  the  number  of  cases  where  surface-to-air  missiles 
fired  from  two  different  ships  are  aimed  at  the  same  threat  (overkill),  chaff  deployed  from 
one  ship  to  decoy  threats  causes  the  threats  to  hit  another  ship  (fratricide),  rotations  from 
two  different  ships  to  use  their  hardkill/softkill  weapons  in  a  more  successful  way  results  in 
a  collision  course  for  each  ship,  and  the  number  of  cases  where  the  rotation  sense  for 
deployment  of  hardkill  and  softkill  weapons  is  opposite  (interference). 

I 

Some  of  the  modeling  done  to  integrate  the  extended  knowledge-based  system  into 
the  AAW  Simulator  is  described  in  Refs.  60-62. 

3.3.3  TEWA  Resource  Loading  Study 

A  TEWA  resource  loading  study  has  been  carried  out  by  Thomson  CSF  Systems 
Canada  to  simulate  the  loads  placed  on  the  command  and  control  processors  of  a  TRUMP 
like  ship  by  battle  management  functions  assigned  to  the  ship’s  UYK  505  processors.  The 
battle  management  functions  were  derived  from  a  generic  TEWA  study  preceding  the  work 
described  in  section  3.3.1  which  described  a  general  air  defence  process,  listed  its 
functions  and  subfunctions  and  presented  flow  diagrams  specifying  the  data  flow  between 
functions  and  subfunctions  of  the  air  defence  process.  In  this  study,  estimates  are  made  of 
the  cycle  time  taken  by  each  UYK  505  processor  for  executing  lines  of  pseudocode 
representing  the  battle  management  functions.  The  simulation  also  measures  the  queue  sizes 
of  messages  sent  from  the  ship’s  sensors  and  weapons  through  the  SHINPADS  bus  into 
the  command  and  control  computers.  The  data  flow  through  the  SHINPADS  bus  of  each 
warship  and  through  the  LINK  1 1  system  connecting  several  ships  are  also  outputs  from 
the  simulation.  Thus,  for  a  high  density  attack  of  air  threats  on  ships,  this  simulation  will 
show  bottlenecks  in  the  CCS  interfaces  caused  by  the  slowness  of  the  UYK  505  processor 
in  executing  Battle  Management  Functions.  The  resource  loading  simulation  is  coded  in 
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SIMSCRIPT  and  runs  on  a  HP  9000/360  work  station.  This  work  is  described  in  Refs. 
63-67. 


In  any  potential  continuation  work  involving  the  Engineering  testbed  proposed  by 
DMSS  8  (see  section  2.6.4),  the  effect  on  communication  protocols  of  implementing  a 
knowledge-based  STA  on  multiprocessor  COTS  platforms  must  be  measured  in  the 
SHINPADS  bus  and  at  the  interfaces  of  the  computers.  If  the  response  of  a  particular 
computer  to  data  from  the  command  and  control  system  or  from  another  COTS  platform  is 
slow,  the  data  accumulation  at  the  computer’s  interface  must  not  hinder  the  functioning  of 
the  testbed. 


3.3.4  Current  Work  in  Situation  and  Threat  Assessment 

In  the  present  formulation  of  STA,  a  model  has  been  built  depending  on  three  real¬ 
time  air  defence  functions:  threat  assessment,  defence  assessment  and  kill  assessment.  The 
threat  assessment  and  defence  assessment  functions  comprise  subfunctions  that  analyze  the 
geometric  proximity  of  air  tracks,  estimate  the  strength  of  enemy  and  own  force  assets  and 
predict  the  enemy's  intentions.  The  subfunctions  of  threat  assessment,  defence  assessment 
and  the  kill  assessment  function  undergo  situation  interpretation  and  situation  prediction, 
i.e.,  an  interpretation  is  made  of  what  the  enemy  or  neutral  forces  are  currently  doing  and 
this  is  followed  by  a  short  term  prediction  of  what  they  will  be  doing  in  the  future.  A  nine 
function  model  for  STA  has  been  devised  in  the  United  Kingdom  (see  Ref.  68)  which 
includes  the  three  functions  mentioned  above  and  additional  functions  such  as  mission 
monitoring.  In  subsequent  work  with  the  ASCACT  testbed,  implementations  of  other 
functions  of  STA  mentioned  in  Ref.  68  could  take  place  in  order  to  estimate  their  feasibility 
for  execution  in  real  time. 

3.3.4. 1  Situation  and  Threat  Assessment  in  Real  Time 

Much  work  has  been  done  to  develop  non  real-time  methods  and  algorithms  for 
STA  (see  Refs.  69-72).  These  methods  depend  on  knowledge  elicitation  procedures  using 
case-based  reasoning  (see  Ref.  69)  or  on  knowledge  acquisition  techniques  based  on  long 
term  memory,  procedural  memory  and  short  term  memory  (see  Ref.  70).  In  order  to  make 
these  approaches  function  in  real  time,  an  external  mechanism  such  as  a  meta-level 
controller  can  be  imposed  on  the  knowledge  structure  to  handle  asynchronous  inputs  and 
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interrupts,  organize  and  schedule  tasks  using  priorities  and  control  the  various  reasoning 
mechanisms  in  order  to  meet  hard  task  deadlines. 

One  approach  in  which  an  external  mechanism  is  imposed  on  a  non-real  time 
system  in  order  to  make  it  function  in  real  time  is  the  design-to-time  approach.  The  design- 
to-time  algorithm  provides  an  approximate  solution  to  a  problem  for  each  time  interval 
during  which  the  algorithm  acts.  After  a  specific  time  interval  which  is  chosen  by  the 
algorithm  designer,  the  solution  returned  is  exact  and  complete.  A  design-to-time  approach 
to  a  real-time  KBS  system  can  be  implemented  by  using  a  meta-level  controller  (see  Ref. 
73). 


An  alternative  real-time  approach  is  to  build  the  artificial  intelligence  application  so 
that  it  will  be  forced  to  satisfy  the  real-time  requirements  of  naval  STA.  The  latter  approach 
is  called  an  anytime  approach  to  artificial  intelligence.  This  approach  to  problem  solving  is 
characterized  by  the  making  of  compromises  between  solution  quality  and  the  execution 
time  of  the  algorithm.  The  algorithm  is  designed  so  that  it  provides  a  solution  to  the 
problem  at  anytime  and  the  quality  of  the  solution  obtained  improves  as  the  algorithm 
execution  time  increases.  A  meta-level  controller  can  be  used  to  implement  anytime 
algorithms  for  artificial  intelligence.  The  meta-level  controller  contains  algorithms  which 
allocate  time  intervals  during  which  the  STA  process  will  operate  on  synchronous  or 
asynchronous  data  received  from  a  suitable  process. 

The  interpretation  of  the  tactical  picture  will  be  made  in  terms  of  confidence  factors 
or  variables  involving  fuzzy  logic.  A  comparison  is  made  between  the  predicted  tactical 
situation  of  the  previous  time  step(s)  and  the  actual  interpreted  tactical  picture  of  the  present 
time  step.  In  an  anytime  implementation  of  STA,  the  time  step  over  which  the  comparison 
is  made  could  be  chosen  by  a  meta-level  controller  (see  Fig.  14  for  a  possible  architecture 
of  a  real-time  STA  process).  The  real-time  STA  process  analyses  the  tracks  to  group  them 
into  collections  of  air  platforms.  An  interpretation  is  made  concerning  what  each  group  is 
currently  doing  (reconnaissance,  surveillance,  over  the  horizon  targeting)  and  what  it  will 
be  doing  in  the  near  future  (bombing,  launching  anti-ship  missiles,  strafing). 

The  threat  assessment  function  of  STA  decides  which  of  the  tracks  in  each  group  of 
platforms  is  a  threat  to  the  ship  and  the  extent  to  which  it  is  a  threat.  It  will  return  an 
indication  in  terms  of  certainty  factors,  fuzzy  logic  or  probability  as  to  which  ships  of  the 
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convoy  are  targeted  by  anti-ship  missiles.  The  extent  to  which  an  air  track  constitutes  a 
threat  to  a  ship  is  characterized  by  numerical  threat  levels  although  alternative  models  are 
currently  being  studied. 

The  defence  assessment  function  estimates  the  state  of  own  force  assets  and 
whether  these  assets  can  engage  the  hostile  targets  at  the  current  time.  In  ST  A  for  multiple 
ship  scenarios,  a  prediction  concerning  the  best  placing  of  AAW  ships  is  required  when  the 
ships  are  attacked  by  air  threats.  In  addition,  if  the  AAW  commander's  air  defence  plan  is 
not  being  followed  by  the  other  ships  of  the  convoy,  the  AAWC  ship  must  monitor  the 
AAW  situation  and  alert  the  ships  of  the  task  force  to  the  fact  that  the  plan  is  not  being 
followed. 

The  kill  assessment  function  monitors  real-time  inputs  from  the  weapon  systems 
and  threat  assessment  function  to  decide  whether  a  threat  has  been  destroyed  by  a  hardkill 
weapon  system  or  by  a  softkill  weapon  system.  In  the  case  of  softkill  assessment,  a 
collaborative  effort  between  the  MSDF  process  and  the  threat  assessment  function  of  the 
STA  process  to  monitor  the  trajectory,  radar  modes  and  EW  characteristics  of  anti-ship 
missiles  would  indicate  the  degree  of  success  as  indicated  by  confidence  factors  of  softkill 
weapons  used  against  these  threats. 

In  the  ASCACT  project,  the  mission  of  all  naval  command  and  control  subsystems 
including  the  STA  process  is  primarily  local  area  defence.  This  means  that  the  STA  process 
resides  in  a  single  ship  which  will  be  part  of  a  Canadian  Forces  or  NATO  task  force  lead  by 
an  AAWC  ship.  This  does  not  imply  that  the  STA  software  architecture  will  be  necessarily 
centralized.  The  choice  of  the  software  architecture  for  STA  will  depend  on  its  interactions 
with  the  MSDF  and  RM  software  units  and  the  results  of  mapping,  scheduling  and.  load 
balancing  studies  for  a  network  of  distributed  workstations  executing  the  integrated 
MSDF/STA/RM  system. 

3.3.4.2  Using  MUSE  for  Situation  and  Threat  Assessment 

Certain  subfunctions  of  the  threat  assessment  function  of  naval  STA  described  in 
section  3.3.4. 1  above  are  being  implemented  as  a  sequence  of  knowledge  sources  in  the 
real-time  knowledge-based  shell  MUSE.  At  the  present  moment,  the  threat  assessment 
function  does  situation  interpretation,  threat  evaluation  and  threat  ranking.  Work  continues 
at  the  current  time  to  determine  the  functionality  of  these  subfunctionS,  their  inputs  and 
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outputs,  how  they  will  process  air  track  and  identity  data  from  the  MSDF  function  and  how 
they  will  generate  output  for  the  resource  management  function.  Ref.  74  which  is  by  no 
means  a  complete  document  on  the  real-time  functional  decomposition  of  the  ST  A  process 
contains  some  details  of  its  subfunctions  and  specification. 

The  current  implementation  with  MUSE  is  design-to-time  in  the  sense  lhat  the 
knowledge  sources  are  allotted  a  certain  amount  of  time  to  calculate  their  result.  A  C 
program  acts  as  an  elementary  meta-level  controller  choosing  a  time  interval  which  is  a 
suitable  multiple  of  the  interval  between  successive  updates  of  the  fastest  fire-control  radar. 
The  MUSE  implementation  can  be  made  into  an  anytime  application  by  adding  various 
control  units  (Poptalk  functions)  to  the  existing  design-to-time  knowledge-based  system 
that  1)  partition  the  air  track  space  2)  partition  the  number  of  knowledge  sources  3)  partition 
the  rulesets  within  each  knowledge  source  according  to  specific  criteria  so  that  the 
inferencing  can  be  done  within  the  required  time  interval.  In  addition,  the  control  units  must 
increase  the  size  of  the  track  space,  the  number  of  knowledge  sources  that  will  undergo 
inferencing  and  the  number  of  rulesets  so  that  the  quality  of  the  STA  increases  with 
calculation  time. 

The  threat  ranking  function  of  STA  which  calculates  threat  levels  for  fused  air 
tracks  has  been  implemented  as  a  60  rule  forward  chaining  knowledge  source  in  the  MUSE 
shell.  The  fused  air  tracks  consist  of  track  position  and  velocity  (radar  data),  the  radar  mode 
of  the  track  (ESM  data)  and  its  ESM  identity.  The  subfunction  of  defence  assessment  that 
assesses  the  state  of  own  force  assets  has  also  been  implemented  as  a  25  rule  forward 
chaining  knowledge  source.  Some  experiments  were  conducted  to  compare  the  real-time 
performance  of  forward  chaining  and  backward  chaining  inferences  in  the  knowledge 
source.  The  experiments  consisted  of  reading  vectors  of  data  at  one  time  stamp  from  an 
exterior  file  into  the  MUSE  knowledge  source.  The  knowledge-based  implementation  of 
these  two  subfunctions  (threat  ranking,  state  of  own  force  assets)  of  the  STA  process  is  a 
design-to-time  approach.  A  stimulator  has  been  built  in  C  for  producing  air  tracks  from 
long  range  radars,  medium  range  radars,  fire-control  radars,  ESM  and  IFF. 

3.4  Resource  Management 

Effective  resource  utilization  is  essential  during  a  military  mission.  Automated 
support  systems  that  aid  warfare  officers  in  resource  management  in  the  time-critical  and 
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stressing  environment  of  naval  warfare  are  expected  to  be  part  of  future  requirements  for 
shipboard  CCISs.  Such  systems  will  need  to  address  the  continuous  cooperative, 
synergistic,  and  efficient  utilization  of  all  resources,  while  providing  increased  flexibility 
and  functionality  for  the  human  operator.  To  this  end,  the  C2  Division  at  DREV  has 
initiated  an  R&D  project  aimed  at  developing  automated  resource  management  systems 
(RMSs)  for  naval  combat  systems.  The  purpose  of  these  systems  is  to  help  the  personnel  to 
optimize  the  utilization  of  scarce  renewable  and  non-renewable  resources  in  defence 
systems,  computational  systems  and  communication  systems.  In  the  process,  they  will 
provide  support  in  and  relief  from  performing  complex  real-time  command  and  control 
(C2)  functions  in  a  demanding  environment.  An  example  is  a  sensor  management  system 
for  controlling  one  or  more  sensors.  One  level  of  functionality  in  such  a  system  could  be 
provided  by  an  adaptive  radar  controller  for  a  multi-function  radar  (MFR)  whose  radar 
variables  must  be  managed  by  the  controller  in  real-time  so  that  it  can  respond  effectively  to 
a  changing  radar  environment,  numerous  operator  commands,  and  a  variety  of  functions 
and  missions.  In  this  manner,  the  MFR  becomes  more  flexible  and  the  use  of  this  resource 
is  optimized. 

The  project  is  currently  addressing  three  broad  real-time  resource  management 
issues:  first,  the  design,  implementation  and  testing  of  adaptive  software  agents  for 
continuous  real-time  allocation  and  scheduling  of  defence,  computational  and 
communication  resources  in  naval  battle  management  systems;  second,  the  enhancement  of 
the  effectiveness  of  these  agents  by  using  concurrent  computing  technology;  and  third,  the 
embedding  of  these  agents  in  a  real-time  control  hierarchy  for  a  supportive,  autonomous 
shipboard  STA/RM  system  for  single  and  multiple  ships  (Ref.  75). 

A  brief  description  is  given  below  of  the  ongoing  DREV  research  in  resource 
management  that  could  form  the  basis  for  this  prototype  implementation  in  ASCACT. 

Our  schematic  of  a  generic  RMS  (Ref.  76)  is  shown  in  Fig.  15.  The  principal  input 
to  the  RMS  is  from  the  STA  system.  This  input,  together  with  human  interaction  via  an 
operator  interface,  as  required  or  as  response  time  permits,  drives  the  planning  and  decision 
support  functions  for  allocating  and  scheduling  the  use  of  critical  resources  and 
coordinating  the  appropriate  action  executions  via  actuator  systems.  Human  interaction  can 
take  the  form  of  commands  to  the  RMS  and/or  requests  for  support  from  the  RMS.  This 
may  entail  informing  or  advising  the  operator  by  providing  him  with  action 
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FIGURE  15  -  A  generic  resource  management  system 

recommendations,  suggestions,  etc.,  depending  on  his  support  requirements  and  on  the 
division  of  responsibility  between  the  RMS  and  the  operator  (man-machine  functional 
allocation). 

Continuously  monitoring  the  effects  of  actions  and  recognizing  the  occurrence  of 
significant  events  in  the  world  that  require  new  or  revised  responses  closes  the  loop  and 
leads  to  adaptive  feedback  control  of  the  external  environment.  Planning  requires  reasoning 
in  time  and  about  time.  Internal  planning  models  need  to  be  consistent  with  the  operator's 
mental  states  (beliefs,  goals,  plans,  etc.)  to  ensure  that  what  is  planned  to  achieve  is  indeed 
what  is  desirable  to  achieve  and  that  the  overall  effect  of  the  management  system  is  to 
improve  the  performance  of  the  operator  in  achieving  his  mission.  Course  of  action 
decisions  may  be  required  periodically  (e.g.,  as  a  result  of  sensor  input)  or  apericdically 
(e.g.,  due  to  sporadic  interactions  with  a  human  operator).  Decisions  need  to  be  made 
continuously  and  executed  concurrently,  all  in  real-time.  The  time  available  for  formulating 
a  response  may  vary  from  one  planning  episode  to  the  next,  as  a  function  of  hard  and  soft 
real-time  constraints  that  depend  on  situation  context.  In  the  combat  environment  of  the 
AWW,  this  time  is  extremely  limited,  generally  ranging  from  a  few  minutes  to  a  few 
seconds.  In  general,  the  velocity  of  significant  change  in  the  environment  and  the  nature 
and  extent  of  the  requirement  for  synchronized  interaction  with  this  environment  dictate 
response  time  in  a  given  situation.  At  the  software  development  level,  this  suggests  the 
need  to  represent  and  encapsulate  temporal  behavior  (deadlines,  types  of  deadlines, 
criticality,  etc.)  so  that  the  RMS  can  adapt  to  changes  in  the  environment  while  reasoning 
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about  the  necessary  tradeoffs  between  response  time  and  the  quality  of  the  response 
(metareasoning). 

Figure  16  presents  a  simplified  representation  of  our  block  specification  of  a  two¬ 
layered  real-time  control  architecture  for  the  Weapon  Engagement  Manager  (WEM)  (Ref. 
76).  It  shows  the  important  functions  (represented  by  blocks)  and  information  flows 
(represented  by  arrows)  in  the  architecture.  No  assumption  is  made  about  the  specific 
underlying  hardware  on  which  the  WEM  is  to  run.  This  is  to  allow  for  hardware 
availability  that  may  vary  dynamically,  as  well  as  for  dynamic  reconfiguration  requirements 
of  the  software  in  a  combat  system  for  reasons  of  survivability. 

A  high-level  description  of  the  functions  in  Fig.  16  is  as  follows.  The  deliberative 
planner  uses  a  planning  technique  known  as  simulation-based  planning;  that  is,  it  computes 
an  effective  plan  for  assigning  and  scheduling  the  use  of  hardkill  and  softkill  weapon 
systems,  and  tracking  and  guidance  systems  over  some  time  horizon,  subject  to 
engagement  doctrine  and  resource  availability,  by  effectively  performing  a  super  real-time 
simulation  of  the  evolution  of  pertinent  features  of  the  combat  environment  over  the  plan 
horizon.  The  planner  provides  service  in  response  to  the  occurrence  of  an  event  arising 
from  a  significant  change  in  the  tactical  picture  that  requires  deliberative  (re)planning. 
Recognizing  such  significant  events  within  temporal  constraints  is  handled  by  the 
characterizer,  using  its  internal  model  of  the  world  and  information  from  the  projector  and 
the  effector.  This  model  permits  nonmonotonic  and  probabilistic  reasoning  about  change 
and  the  effects  of  actions  and  their  effectiveness  over  a  look-ahead  horizon.  The  projector 
maintains  information  corresponding  to  extrapolations  of  the  state  of  the  world  over  the 
forecast  horizon.  Among  other  things,  projection  entails:  extrapolating  potentially  hostile 
tracks  and  ship  maneuvers;  projecting  occurrences  of  events  arising  from  ongoing 
engagements,  previously  committed  actions,  etc.,  including  outcomes  of  defence  actions 
and  threat  strikes  on  own  ships;  predicting  when  potentially  hostile  tracks  will  be 
engageable,  from  which  ships  and  by  which  weapon  systems  on  such  ships,  as  well  as 
measures  of  effectiveness  of  such  defensive  actions;  predicting  effects/restrictions 
associated  with  obstructions  (parts  of  a  ship's  structure,  chaff  clouds,  offboard  decoys, 
etc.),  environmental  conditions,  or  operational  constraints  (EMCON,  risk  of  fratricide, 
etc.)  which  preclude  terminal  illumination  or  threat  interception,  or  which,  at  least, 
significantly  degrade  effectiveness  of  actions;  and  predicting  positive  and  negative 
interactions  that  result  from  concurrent  use  of  hardkill  and  softkill  weapon  systems.  By 
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Engagement  Manager 


Tactical  Weapon 

Situation  Data  Controllers 


FIGURE  16  -  Layered  software  architecture 
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communicating  with  the  various  weapon  controllers,  the  effector  coordinates  and  directs  the 
execution  of  plans  received  from  the  planner  and  uses  tactical  situation  fluents  to  monitor 
outcomes  of  defensive  actions. 

To  allow  the  planner  to  make  tradeoffs  in  real-time  between  response  time  and  the 
quality  of  its  planning,  a  time-dependent  planning  technique  has  been  developed.  It  is  based 
on  our  notion  of  almost  anytime  planning  (Ref.  77).  The  underlying  idea  is  to  control  the 
amount  of  computation  involved  in  plan  generation  by  using  a  rolling  plan  horizon  whose 
size  is  determined  at  the  time  of  a  service  call  on  the  deliberative  planner.  Both  contract  and 
interruptible  planning  variants  are  being  explored.  In  contract  mode,  the  planner  produces  a 
plan  within  a  compute  time  that  is  specified  at  the  time  of  its  service  call.  In  interruptible 
mode,  the  compute  time  is  not  specified  and  the  planner  can  be  interrupted  unexpectedly. 
Such  planners  therefore  allow  for  a  continuum  of  completion  times  under  time  pressure. 
We  are  also  investigating  other  approaches  to  limiting  complexity,  including  using  a  suite 
of  planners  that  employ  multiple  and  approximate  methods,  running  in  parallel  under  the 
supervision  of  a  metalevel  controller. 

A  specific  rational  agent  model  for  planning  surface-to-air  missile  (SAM) 
engagements  has  been  developed  along  with  algorithms  for  its  implementation  (Refs.  75- 
81).  Planning  is  utility-driven.  This  provides  a  normative  basis  for  rational  choice  under 
uncertainty.  SAM  engagement  plans  are  conditional  or  contingent  in  the  sense  that 
uncertainty  in  the  outcomes  of  SAM  engagements  are  explicitly  accounted  for  inside  the 
plan  itself  by  incorporating  defence  actions  and  activities  to  allow  reactive  response  (when 
feasible)  in  case  of  unsuccessful  engagements.  A  plan  is  therefore  closed-loop,  with  certain 
of  its  actions  conditional  on  outcome  assessments  available  to  the  effector  at  plan  execution 
time  from  reactive  plan  execution  monitoring  or  real-time  kill  assessment.  The  advantage  of 
this  approach  is  that  it  limits  the  need  for  deliberative  replanning  in  time-critical  situations. 
Its  price,  however,  is  a  potentially  greater  computational  load  in  generating  each  conditional 
plan.  This  is  in  contrast  to  an  alternative  planning  approach,  based  on  open-loop  or 
unconditional  planning.  In  this  second  approach  which  is  also  being  examined,  no 
consideration  is  given  to  planning  for  contingencies  and  the  fact  that  knowledge  of  the 
outcomes  of  threat  engagement  will  become  available  at  the  time  of  plan  execution  is 
ignored.  This  has  the  effect  of  trading  off  plan  quality  for  reduced  computational 
complexity  of  each  plan  generation;  however,  more  frequent  real-time  replanning  will  be 
required. 
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Planning  SAM  engagements  over  a  given  planning  horizon  is  computationally 
intensive.  We  are  therefore  investigating  the  use  of  distributed  and  high-performance 
computing  to  aid  with  these  computations.  The  tools  being  used  for  this  work  include: 

•  DREV's  4K  processor  CM2a  SIMD  machine  from  Thinking  Machines 
Corporation; 

•  Proteus  System,  a  high-performance  parallel  architecture  simulator  that 
can  simulate  at  instruction  level  granularity  a  variety  of  MIMD 
multiprocessors;  and 

•  PVM  (Parallel  Virtual  Machine)  and  SAM,  two  public  domain  software 
frameworks  that  together  allow  shared-memory  heterogeneous  concurrent 
computing  in  networked  environments 

Preliminary  static  open-loop  tests  of  performance  of  our  MIMD  algorithms  for  the 
SAM  planner  (using  the  Proteus  System)  indicate  that  their  computational  performance 
scales  linearly  with  the  size  of  the  parallel  machine  used  in  implementations  (Refs.  76,  78- 
79).  This  result  strongly  indicates  the  feasibility  of  using  advanced  deliberative  planning 
techniques  in  the  WEM  and  points  the  way  ahead  for  further  experimentation  involving 
closed-loop  testing  on  the  ASCACT  testbed.  Experiments  are  in  progress  on  the  CM2a. 
Preliminary  performance  testing  using  PVM  and  SAM  on  the  C&C  network  of 
SPARCstations  is  only  just  getting  started. 

Finally,  we  mention  two  other  R&D  efforts  which  may  impact  some  of  the  specifics 
of  an  implementation  and  performance  testing  of  a  WEM  within  the  ASCACT  testbed: 

•  an  NSERC  collaborative  R&D  grant,  involving  DREV,  Loral  Canada,  and 
Universite  de  Montreal  (CRT)  aimed  at  further  specifying  the  design  and 
implementation  of  various  resource  managers  to  support  real-time 

* 

decision-making  has  been  awarded;  and 

•  a  DIR  project  has  been  awarded  to  Maple  Computer  Systems  aimed  at 
expanding  the  current  potential  of  simulation  technology  to  permit 
simulating  larger  components  of  a  distributed  battle  management  system 
(e.g.,  sensor  data  fusion,  situation  assessment,  and  resource 
management)  and  evaluation  of  their  real-time  performance  in  both  open- 
loop  and  closed-loop  scenarios. 
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3.5  MSDF/STA/RM  Integration 

For  historical  reasons,  previous  MSDF,  STA  and  RM  R&D  activities  by  members 
of  the  Data  Fusion  and  Resource  Management  Group  have  approached  the  problem  of 
satisfying  perceived  future  shipboard  CCIS  data  and  information  processing  requirements 
in  an  essentially  discrete,  bottom-up  manner.  MSDF  has  focused  on  analyzing,  developing 
and  evaluating  advanced  techniques  to  automatically  produce  the  optimal  estimate  of  the 
position,  kinematic  behavior,  and  identification  of  all  objects  surrounding  a  single  ship, 
mainly  through  the  fusion  of  data  from  dissimilar  organic  sensors,  while  including  non- 
organic  information.  STA  has  been  concerned  with  providing  reliable  assessments  of  the 
situation  in  which  the  ship  is  operating  that  are  important  for  the  successful  accomplishment 
of  the  mission.  Finally,  RM  has  aimed  to  provide  planning  and  decision  support 
functionality  in  the  CCIS  to  aid  military  personnel  in  the  integrated  use  of  critical  resources 
and  to  manage  their  coordination  in  accordance  with  such  decisions.  The  decision-making 
referred  to  here  relates  to  refining  and  enhancing  perception  (i.e.,  sensor  management)  as 
well  as  the  management  of  the  ship's  hardkill  and  softkill  weapon  systems. 

Despite  the  apparent  compartmentalization  of  previous  R&D  efforts  in  the  group, 
where  the  focus  of  individual  efforts  has  been  largely  shielded  from  each  other,  it  is  clear 
that  in  future  shipboard  CCISs  the  MSDF,  STA  and  RM  processes  will  need  to  work 
together  in  an  integrated,  synergistic  manner.  Therefore,  while  MSDF  outputs  low  level 
perceptions  of  the  tactical  picture,  STA  uses  these  to  provide  the  higher-level  abstractions 
needed  to  interpret  their  meaning  and  tactical  significance.  The  principal  observe-orient- 
decide-act  (O-O-D-A)  C2  loop  is  then  closed  via  RM,  thereby  providing  effective  response 
in  support  of  the  mission  to  significant  events  in  the  external,  hostile  battle  environment. 

In  parallel  with  continuing  efforts  within  the  group  to  effect  refinements  and 
improvements  in  the  individual  processes,  an  important  new  research  focus  has  therefore 
emerged  recently,  aimed  at  addressing  this  integration  problem  in  a  top-down  manner  and 
at  evaluating  its  potential  solutions.  The  end  goal  of  this  research  is  the  design  of  a  real¬ 
time,  semi-automated  advisory  decision  support  system,  called  an  MSDF/STA/RM  system, 
that  continuously  take  in  data  from  the  ship’s  sensors  and  other  information  sources,  build 
an  accurate  air  tactical  picture  as  quickly  as  possible,  provide  the  most  likely  interpretation 
of  the  tactical  situation,  suggest  options  to  defend  the  ship  using  the  best  possible 
combination  of  hardkill/softkill  weapons  or  other  defensive  means  (e.g.,  suggest  an 
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optimal  sequence  of  sensor  and  weapon  allocations)  and  present  fused  information  and 
decision  support  analysis  results  with  the  opportunity  for  the  Commanding  Officer  and 
Above  Water  Warfare  (AWW)  team  to  accept/reject  recommended  actions/plans  in  a  timely 
manner,  and  coordinate  and  direct  execution  of  these  actions/plans. 

3.6  Conceptual  Framework  Study 

In  collaboration  with  DMSS  8,  DREV  is  currently  looking  at  different  software 
architectures  for  the  C2  functions  of  Canadian  warships.  A  necessary  requirement  for 
further  R&D  in  this  area  is  to  develop  an  operational  conceptual  framework,  projecting 
twenty  years  into  the  future,  that  would  be  used  to: 

•  study  the  functionality,  interrelation  and  real-time  properties  of  the 
shipboard  C2  functions  in  preparation  for  grouping  them  together  into 
units  of  operational  significance, 

•  help  identify  the  current  areas  of  deficiencies  in  the  Canadian  navy's 
capabilities  and  suggest  ways  in  which  these  deficiencies  could  be 
corrected, 

•  provide  a  framework  supporting  the  definition  and  orientation  of  future 
maritime  R&D  projects,  and, 

•  formulate  recommendations  about  cost  effective  incremental 
improvements  to  the  capabilities  of  Canadian  ships. 

As  an  initial  step  toward  the  development  of  such  a  conceptual  framework,  DMSS  6 
has  developed  and  proposed  a  model,  for  AAW  only,  that  is  illustrated  in  Fig.  17.  The 
functions  of  this  framework  are  divided  into  sensor,  C2  and  weapon  functions.  The  combat . 
system  functions  of  the  NFR  90  are  also  being  considered  as  a  potential  model  for  the 
development  of  the  required  conceptual  framework. 

In  this  context,  a  study  entitled:  "Conceptual  Framework  for  Studying  the  Future 
C&C  Requirements  of  Canadian  Warships"  has  been  defined  by  DREV  and  DMSS  8.  As 
part  of  this  study,  both  the  DMSS  6  and  the  NFR  90  models  will  have  to  be  assessed  for 
completeness;  they  will  then  have  to  be  refined  and  expanded  to  provide  the  final  product. 

Originally,  the  conceptual  framework  study  was  planned  as  a  project  in  three:  parts: 


Figure  17  -  Conceptual  framework  initially  proposed  by  DMCS  4 
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1)  definition  of  the  C2  functions  of  the  framework; 

2)  system  integration  study  designed  to  map  the  conceptual  framework: 
functions  of  part  1  into  the  combat  system  of  the  CPF;  and, 

3)  R&D  study  indicating  future  research  directions  which  would  be 
desirable  for  the  C2  functions  of  the  conceptual  framework. 

However,  it  has  been  decided  to  follow  a  phased  approach  and  to  undertake  only 
the  first  part  of  the  conceptual  framework  study  for  the  moment.  A  statement  of  work 
(SOW)  describing  the  work  which  must  be  done  in  order  to  define  the  C2  functions  of  the 
conceptual  framework  has  thus  recently  been  prepared. 

The  recommendations  of  such  a  study  defining  the  inputs  and  outputs  of  shipboard 
C2  functions,  their  interrelation  and  their  real-time  properties  can  be  used  to  help  design  the 
software  architecture  of  MSDF,  STA  and  RM  functions  for  an  implementation  in  a  real¬ 
time  distributed  multiprocessor  environment  such  as  the  ASCACT  testbed. 

3.7  Collaborative  Project  with  the  Industry 

There  has  been  a  lot  of  work  performed  in  Canada  to  investigate  various  aspects  of 
the  MS DF/STA/RM  technologies  for  application  on  CPF.  This  work  has  mostly  been  done 
as  investigations  conducted  by  DREV  and  its  contractors  and  collaborators  (industry  and 
university),  analyzing  and  demonstrating  various  MSDF/STA/RM  methods  for  the  CPF. 
While  these  investigations  have  addressed  a  broad  range  of  issues,  they  do  not  cover  all 
aspects  of  an  automated  CCIS  using  MSDF/STA/RM  techniques  and  methods  in  real-time. 
The  research  up  to  now  has  provided  certain  pieces  of  the  puzzle  (i.e.,  automated  CCIS  of 
the  future  CPF),  while  some  other  pieces  still  need  to  be  added  to  complete  the  picture.  The 
missing  pieces  represent  some  MSDF/STA/RM  techniques/methods  which  are  not  yet  fully 
understood  for  implementation  on  CPF,  or  techniques/methods  that  are  understood,  but 
their  real-time  implementations  have  not  yet  been  proven.  These  could  be  actualized  by 
performing  a  number  of  small  and  separate  R&D  activities  which  then  would  be  fitted  into 
an  automated  CCIS.  However,  there  are  drawbacks  to  this  approach;  it  would  be  very 
difficult  to  ensure  that  the  complete  picture  is  covered,  and  that  the  interfaces  between  the 
pieces  are  compatible.  Furthermore  each  separate  task  would  have  to  build  its  own 
expertise  and  framework,  before  actually  performing  the  research,  increasing  the  cost  of  the 
overall  program  in  the  redundant  activities  for  each  task.  It  would  be  much  more  efficient  to 
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build  the  missing  pieces  into  a  complete  set  of  proven  techniques/methods  working  in  real 
time  (which  can  be  the  building  blocks  of  the  future  automated  CCIS  for  CPF)  as  part  of  a 
complete  coordinated  project,  based  on  the  existing  expertise,  framework  and  proof-of- 
concept  software  available  from  the  above  mentioned  work. 

To  ensure  that  existing  funding,  people  and  facilities  are  used  optimally  in  such  a 
project,  DREV  has  formed  a  collaborative  partnership  with  Loral  Canada.  The  top  level  aim 
of  this  ongoing  project  is  to  capture  and  analyze  the  real-time  requirements  of  a  CPF  C2 
system  integrating  MSDF,  STA  and  RM,  using  all  information  available  on  the  CPF  (or 
future  CPF).  The  R&D  activities  are  jointly  managed  by  Loral  and  DREV,  who  meet 
regularly  to  evaluate  the  results  of  the  research  and  to  agree  on  future  directions  to  be  taken. 

3.7.1  Simulated-Real-Time  Environment  (SRTE) 

A  cornerstone  of  the  proposed  methodology  for  capturing  the  MSDF/STA/RM 
system  requirements  for  the  ASCACT  integration  testbed  is  the  design  and  implementation 
of  a  simulated-real-time  environment  (SRTE)  for  evaluating  concepts,  algorithms  and 
architectures  for  MSDF/STA/RM.  In  this  methodology,  all  real-time  system  development 
and  experimentation  is  conducted  on  a  simulator  running  on  a  host  (uniprocessor) 
architecture  and  the  purpose  is  to  capture  the  functional  requirements,  temporal  behavior 
and  real-time  performance  of  the  integrated  MSDF/STA/RM  system.  The  simulation  engine 
in  the  proposed  environment  will  simulate  the  real-time  execution  of  the  MSDF/STA/RM 
system  running  on  a  user  configured  target  hardware  architecture,  interacting  with  its  user- 
specified  environment.  The  target  could  be  a  single  parallel  machine  or  a  collection  of 
(heterogeneous)  machines  connected  via  a  LAN.  The  simulator  will  accurately  simulate  the 
timing  behavior  of  system  code  running  on  the  processors  of  the  target.  At  the  same  time,  it 
will  interleave  events  associated  with  computation  and  communication  between  threads 
running  on  the  same  processor  (machine)  or  different  processors  (machines)  with  events 
that  arise  from  interactions  between  MSDF/STA/RM  and  the  external  battle  world  in  which 
it  is  operating.  This  environment  will  permit  debugging,  testing  and  nonintrusive 
performance  monitoring  of  MSDF/STA/RM  code.  Finally,  both  open-loop  and  closed-loop 
analyses  of  real-time  system  behavior  will  be  achievable. 
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With  respect  to  the  ASCACT  project,  it  is  expected  that  the  SRTE  tool  established 
during  the  collaborative  project  could  serve  multiple  goals  (conditional  to  an  appropriate 
match  with  the  tight  schedule  constraints  of  the  ASCACT  project): 

1 .  help  in  the  capture  of  the  baseline  MSDF/STA/RM  application  real-time 
requirements  in  support  of  the  development  of  the  SOW  for  the  Project 
Definition  Study  (PDS)  for  the  Integration  Phase  (INTPDS), 

2 .  provide  support  to  DND  and  the  eventual  contractor  during  the  conduct 
of  the  INTPDS,  and, 

3.  provide  support  to  DND  and  the  eventual  contractor  during  the 
implementation  sub-phase  of  the  Integration  Phase. 

An  ideal  design  for  the  SRTE  tool  would  permit,  during  future  application 
development,  switching  back  and  forth  between  the  SRTE  and  the  real-time  ASCACT 
testbed  in  a  manner  that  requires  only  recompilation  of  application  code.  The  idea  behind 
this  is  to  then  have  SRTE  function  as  a  powerful  system  development  environment  for  the 
ASCACT  testbed. 

The  collaborative  project  will  conduct  an  evaluation  of  various  simulation  tools  for 
their  suitability  in  implementing  the  SRTE  either  on  top  of  them  or  by  their  integration  into 
the  environment. 
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4.0  RATIONALE  AND  FRAMEWORK  FOR  A  REAL-TIME 
MSDF/STA/RM  IMPLEMENTATION 

In  this  chapter,  we  identify  and  discuss  the  main  motivation  behind  DREV's  interest 
in  a  real-time,  integrated  MSDF/STA/RM  implementation  in  the  ASCACT  testbed.  The 
specific  factors  that  motivate  DREV's  use  of  this  testbed  are  first  discussed  with  respect  to 
each  of  the  main  areas  of  research  taken  individually  (i.e.,  MSDF,  STA  and  RM).  Then  the 
integration  aspect  is  addressed.  Finally,  the  rationale  for  the  selection  of  an  appropriate 
MSDF/STA/RM  integration  framework  is  presented  in  the  last  section  of  this  chapter,  along 
with  a  first  high-level  cut  at  its  design. 

4.1  Multi-Sensor  Data  Fusion 

As  presented  in  section  3.2,  a  lot  of  work  on  the  use  of  the  MSDF  technology  in  a 
naval  context  has  been  conducted  by  DREV.  However,  in  spite  of  the  broad  range  of  issues 
that  have  been  studied  so  far,  some  very  practical  and  important  aspects  still  need  to  be 
given  more  emphasis. 

In  particular,  the  implementation  of  a  real-time  MSDF  function,  taking  into  account 
the  constraints  imposed  by  the  complete  C2  system,  is  a  critical  aspect  of  the  MSDF 
domain  which  has  only  been  given  limited  consideration  so  far  (Ref.  20).  Hence,  a  major 
objective  of  an  MSDF  development  in  ASCACT  is  to  explore  real-time  sensor  data  fusion 
concepts  (position,  identification)  that  could  apply  to  the  current  CPF  and  its  potential 
upgrades,  in  order  to  improve  its  AWW  performance  against  the  predicted  future  threat. 
Closing  the  loop  with  the  situation/threat  assessment  and  resource  management  functions  in 
an  integrated  CCS  is  an  essential  validation  step  to  fully  demonstrate  and  evaluate  the 
benefits  of  MSDF.  ASCACT  provides  a  good  opportunity  to  investigate  the  interactions 
between  STA,  RM  and  MSDF  in  a  real-time  implementation. 

The  database  management  and  query  languages  issue  and  the  interaction  of  the 
MSDF  process/system  with  its  user/operator  (i.e.,  the  HCI,  operator  display  management 
issue)  are  other  aspects  which  have  only  been  briefly  addressed  under  the  MSDF  project  at 
DREV  (Ref.  21).  These  issues  will  be  explored  in  more  depth  with  the  ASCACT  testbed. 
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4.2  Situation  and  Threat  Assessment 

One  purpose  of  studying  naval  STA  in  the  ASCACT  testbed  is  to  study  the  real¬ 
time  performance  of  artificial  intelligence  structures  for  STA  when  they  interface  with 
numerical  sensor  data  fusion  algorithms  and  anytime  algorithms  for  resource  management. 
In  the  ASCACT  testbed,  the  STA  software  will  be  subjected  to  an  approximation  of  the 
real-time  anti-air  warfare  environment  of  the  CPF  and  its  performance  can  be  compared 
with  that  of  data  fusion  and  resource  management  so  that  all  of  these  functions  respond 
suitably  against  a  multiple  threat  air  attack.  In  addition,  the  data  which  has  been  used  to  test 
real-time  STA  algorithms  up  to  the  present  time  has  been  of  a  limited  nature  though 
reasonably  accurate.  The  ASCACT  testbed  will  be  a  place  to  test  the  real-time  performance 
of  STA  algorithms  with  data  of  a  more  diverse  nature  coming  from  a  real-time  MSDF 
process. 

Another  purpose  for  using  the  ASCACT  testbed  is  to  study  the  performance  of 
artificial  intelligence  (knowledge-based  systems,  fuzzy  expert  systems,  neural  networks 
and  case-based  reasoning  tools)  in  real  time  on  multiprocessor  architectures.  An  important 
objective  will  be  to  compare  the  real-time  performance  of  a  multiprocessing  system  for  an 
AI  naval  STA  process  as  compared  with  the  real-time  performance  of  a  uniprocessor 
system  for  the  same  AI  naval  STA  process  and  list  the  advantages  and  disadvantages  of  the 
multiprocessor  system  as  compared  with  the  uniprocessor  system.  The  main  reason  is  to 
determine  the  best  multiprocessing  architecture  for  a  CPF  environment.  The  multiprocessor 
system  will  be  compared  with  the  uniprocessor  system  to  evaluate  how  much  better  it  is  in 
terms  of  satisfying  deadlines,  responding  to  interrupts  and  resetting  task  priorities.  In  order 
to  achieve  this  main  objective,  a  series  of  sub-objectives  will  be  studied,  including  the 
mapping  of  knowledge  bases  (fuzzy  expert  systems,  neural  networks,  hypothesize  and  test 
structures)  onto  processors  of  the  multiprocessor  architecture;  the  scheduling  of  aperiodic 
and  periodic  tasks  which  are  generated  by  the  AI  processes  residing  on  these  processors. 
Moreover,  an  attempt  will  be  made  to  obtain  numerical  estimates  for  the  timeliness, 
responsiveness  and  graceful  degradation  of  the  AI  system  to  real-time  data.  The  testbed  and 
its  environment  will  be  used  to  test  algorithms  which  could  increase  the  speed  of  the 
multiprocessing  system  in  the  knowledge-based  naval  STA  application. 
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Another  reason  for  using  the  ASCACT  testbed  as  a  real-time  experimental  testbed  is 
to  evaluate  the  real-time  performance  of  the  naval  ST  A  models  in  a  closed  loop  combat 
system  simulator.  It  is  envisaged  that  design-to-time  and  anytime  algorithms  for  the 
knowledge  source  STA  model  described  above  in  section  3.3.4. 1  or  a  modified  version  of 
it  will  be  implemented  on  multiprocessor  COTS  platforms  of  the  ASCACT  testbed.  Fuzzy 
expert  systems  will  be  built  on  the  COTS  platforms  of  the  testbed  to  model  the  adversarial 
planning  function  of  STA.  A  comparison  will  have  to  be  made  to  assess  the  benefits  of 
adversarial  planning  using  fuzzy  systems  for  a  STA  process  compared  with  a  knowledge- 
based  system  that  performs  only  threat  ranking. 

The  knowledge-based  STA  process  makes  use  of  several  new  ideas  such  as  tactical 
situation  prediction  and  the  monitoring  of  defence  assessment  plans.  Further  work  that 
could  be  done  in  the  testbed  is  to  measure  the  quality  of  the  tactical  situation  prediction 
obtained  by  the  knowledge  bases  as  a  function  of  the  number  of  ships  and  threats  in  the 
scenario.  Since  situation  prediction  involves  hypothesizing  a  case  and  then  rejecting  or 
accepting  this  hypothesis,  the  function  will  have  to  store  many  cases  and  then  find  the 
correct  case  within  the  real-time  requirements.  The  testbed  will  be  an  ideal  place  for  testing 
the  real-time  performance  and  accuracy  of  the  situation  prediction  algorithms.  A 
knowledge-based  STA  module  will  be  built  comprising  threat  assessment,  defence 
assessment  and  kill  assessment  functions  performing  situation  interpretation  and  prediction 
of  the  tactical  situation  within  the  stringent  real-time  constraints  of  anti-air  warfare.  The 
quality  of  the  tactical  picture  produced  by  the  anytime  algorithms  will  be  assessed  by 
various  measures  of  performance.  The  system  will  be  designed  to  process  real-time  data 
coming  from  the  MSDF  function  and  will  distinguish  peaceful  scenarios  from  hostile  ones. 
The  hostile  scenarios  will  be  assessed  by  the  threat  assessment  and  defence  assessment 
functions  of  STA. 

The  overall  performance  of  the  STA  module  is  controlled  by  a  meta-level  controller. 
The  ASCACT  testbed  could  be  used  for  investigating  the  form  of  the  meta-level  controller. 
The  options  to  be  considered  are:  utility  functions  or  knowledge-based  systems.  Depending 
on  the  tactical  situation,  the  meta-level  controller  will  supply  one  or  several  time  intervals 
during  which  the  STA  module  will  be  required  to  produce  a  response.  The  design  of  the 
meta-level  controller  will  be  made  in  order  to  accommodate  the  overall  real-time 
requirements  of  the  MSDF/STA/RM  process. 
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The  ASCACT  testbed  has  a  real-time  database  capability.  Hence  an  objective  for 
research  in  the  ASCACT  testbed  will  be  to  study  the  interaction  in  real  time  of  these 
databases  with  the  knowledge-based  STA  module  in  multiple  aircraft  and  anti-ship  missile 
scenarios. 

4.3  Resource  Management 

All  of  the  work  reviewed  in  section  3.4  has  been  performed  entirely  in-house  at 
DREV.  While  it  has  from  the  outset  focused  on  a  range  of  real-time  issues,  the  lack  of  a 
suitable  testbed,  associated  tools  and  human  resources  has  of  necessity  restricted  concept 
exploration  studies  to  static  open-loop  testing  of  certain  time-critical  parts  of  a  specific 
RMS.  The  objectives  of  a  resource  management  implementation  in  the  ASCACT  testbed 
have  to  do  therefore  with  a  considerable  widening  of  the  focus  of  the  current  work  to 
include  a  broader  and  more  realistic  range  of  real-time  implementations  leading  to  a 
prototype  RMS  in  an  integrated  MSDF/STA/RM  system.  In  addition,  the  work  will 
encompass  both  static  open-loop  testing  and  dynamic  closed-loop  performance  evaluations. 

The  specific  RMS  to  be  part  of  this  study  is  a  weapon  engagement  manager  (WEM) 
in  a  supportive,  autonomous  system.  The  problem  is  to  continuously  help  a  warfare  officer 
decide  about  the  allocation  and  engagement  scheduling  of  weapons  for  a  single-ship 
(coordinated  engagement)  or  for  a  convoy  of  ships  (both  coordinated  and  cooperative 
engagement)  under  attack  by  air  and  surface  threats.  The  role  of  the  manager  is  therefore  to 
plan,  coordinate  and  direct  in  real-time  point  or  local  area  AWW  defence  actions  involving 
hardkill  and  softkill  weapon  systems  to  achieve  mission  goals  in  response  to  requests  for 
support  or  commands  from  the  warfare  officer. 

In  addition  to  the  architectural  and  algorithmic  aspects  associated  with  the  design  of 
the  manager,  it  is  expected  that  this  work  will  also  study  issues  related  to  automated  RM  as 
a  support  and  decision  aid,  including  support  requirements  of  the  operator,  various  context- 
dependent  modes  for  the  division  of  responsibility  between  the  system  and  the  operator, 
and  decision-making  protocols  for  the  various  modes. 

The  specific  objectives  of  the  work  related  to  a  WEM  implementation  in  the 
ASCACT  testbed  may  be  summarized  as  follows: 
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•  to  implement  and  analyze  adaptive  techniques  for  integrating  planning, 
control  and  coordination  of  weapon  systems  and  at  the  same  time 
prototype  a  decision  aid  or  RMS  for  the  use  of  these  resources; 

•  to  implement  and  analyze  software  architectures  and  associated  concepts 
for  integrated  real-time  resource  management  in  the  AWW  that  aid  in 
designing  systems  which  satisfy  both  logical  and  temporal  requirements; 
and 

•  to  implement  and  analyze  sequential  and  parallel/distributed  algorithms  for 
planning  and  effecting  in  real-time  the  coordination  of  weapon  systems  in 
the  AWW  and  to  quantitatively  demonstrate  via  both  open-loop  and 
closed-loop  testing  the  benefits  of  distributed  and  high-performance 
computing  for  improving  combat  system  performance. 

The  end  goals  of  the  work  are:  to  establish  proof-of-concept;  to  develop  a  capability 
for  specifying,  implementing,  validating,  and  evaluating  real-time  system  integration 
concepts  to  support  future  shipboard  requirements  for  real-time  resource  management;  and 
to  reduce  risk  in  any  potential  follow  on  development  stage. 

4.4  MSDF/STA/RM  Integration 

In  Section  3.5,  we  proposed  the  integration  of  MSDF,  STA  and  RM  in  a  combined 
system,  which  we  refer  to  as  the  MSDF/STA/RM  system,  as  a  major  new  R&D  focus  of 
the  group.  These  processes  are  naturally  interconnected  in  the  O-O-D-A  C2  loop;  for 
example,  Section  3.5  has  hinted  at  their  input/output  relationships.  However,  these  and 
other  relationships  remain  to  be  more  clearly  defined  and  understood. 

At  a  high-level,  we  know  that  integration  requires  optimal  use  in  real-time  of 
available  organic  and  non-organic  information  to  build  a  coherent  tactical  picture  to  support 
human  or  automated  decision-making  and  to  provide  effective  response  coordination. 
However,  the  specifics  of  this  integration  have  yet  to  be  circumscribed.  For  example,  we 
have  only  mentioned  the  principal  O-O-D-A  loop,  but  many  subloops  involving 
information  flows  at  different  velocities  with  the  man  in  the  loop  at  a  variety  of  levels  and  in 
varying  roles  are  in  reality  involved.  Moreover,  both  for  the  sake  of  the  performance  of  the 
individual  processes  and  the  overall  performance  of  the  integrated  system,  there  is  the 
important  matter  of  specifying  the  temporal  dimensions  of  the  system's  behaviors.  The  fact 
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is  that  integration  has  to  achieved  in  an  environment  in  which  response  times  are  at  a 
premium  and  the  necessity  for  a  variety  of  synchronized  interactions  at  various  points  of 
these  loops  with  the  combat  environment  can  require  some  critical  timing  constraints  on 
system  behavior  to  be  satisfied.  In  addition,  it  is  likely  that  such  integration  will  require 
vastly  increased  computing  capabilities  than  is  present  in  the  current  generation  of  naval 
surface  combatants  if  satisfactory,  predictable  and  robust  real-time  behavior  of  the 
integrated  system  is  to  be  achieved.  Questions  of  identifying  how  much  additional 
computational  capability  is  required  and  where,  as  well  as  the  benefits  to  the  C2  system  to 
be  derived  from  such  increased  capability,  are  important  issues  that  need  to  be  addressed. 

In  view  of  this  discussion,  it  should  therefore  come  as  no  surprise  that  some 
significant  challenges  for  the  design  of  automated  tactical  CCISs  will  have  to  be 
confronted.  A  key  goal  is  the  development  of  a  methodology  for  achieving  this  integration, 
which,  ideally,  is  independent  of  the  particular  weapon  and  sensor  technologies  involved 
and  which  allows  for  the  incorporation  of  inevitable  advances  in  computer  hardware  and 
software  technologies. 

Finally,  it  is  important  to  note  that  an  essential  step  in  establishing  this  methodology 
is  the  development  of  the  AS  C ACT  testbed  as  a  versatile  testbed  that  can  serve  as  a  tool  for 
extensive  exploratory  and  empirical  analyses  and  evaluation  of  theoretical  concepts  that  are 
fundamentally  important  to  achieving  this  integration.  This  testbed  will  therefore  have  a 
major  role  to  play  in  studying  the  problems  associated  with  MSDF/STA/RM  integration.  In 
addition,  it  will  provide  a  serious  basis  for  evaluating  our  past  R&D  progress  and  making 
important  tradeoff  decisions  related  to  our  future  efforts  in  MSDF,  ST  A  and  RM.  For 
example,  for  the  first  time  we  shall  be  in  a  position  to  start  providing  well-founded  answers 
to  fundamental  questions  like:  what  are  the  individual  and  collective  performances  of  these 
processes  that  can  be  realistically  automated  in  real-time?;  how  do  we  know  that  our  work 
on  theoretical  concepts  is  leading  to  realizable  performance  improvements  on  board  the  ship 
and  what  is  their  impact  (both  absolute  and  relative)  on  improving  mission  success?;  in 
short,  how  do  we  know  we  are  making  progress,  and  at  what  cost?  While  this  is  clearly  an 
ambitious  path  to  follow,  it  is  an  essential  and  much  needed  one. 


P435278.PDF  [Page:  97  of  128] 


UNCLASSIFIED 

81 


4.5  Preliminary  Definition  of  an  Integration  Framework 

The  discussion  in  Section  4.4  strongly  suggests  that  the  selection  of  an  appropriate 
MSDF/STA/RM  integration  framework  as  a  basis  for  subsequently  defining  a  baseline 
application  in  the  ASCACT  testbed  is  an  important  issue  to  be  resolved.  (The  purpose  of 
the  baseline  application  will  be  to  serve  as  a  proof  of  concept  of  the  ASCACT  testbed.)  The 
remainder  of  this  section  is  therefore  devoted  to  briefly  presenting  the  rationale  for  the 
selection  of  this  framework  and  to  describing  a  first  cut  at  its  design.  Further  details  and 
refinements  of  this  framework  will  be  given  in  the  second  document  to  be  delivered  for  the 
task. 


A  number  of  requirements  on  the  integration  framework  have  been  identified.  Some 
general  requirements  are  as  follows: 

•  it  should  be  compatible  with  an  evolutionary  approach  to  system  design; 
in  particular,  this  means  that  it  should  be  very  flexible,  easily  amenable  to 
extension  and  updating  with  upgrades  in  hardware  and  software 
technologies  and  as  DREV's  R&D  efforts  in  MSDF,  STA  and  RM 
mature; 

•  it  should  be  highly  modular  to  facilitate  independent,  incremental 
extension  of  its  subparts,  as  well  as  multiple  implementations  of  these 
subparts  both  for  purposes  of  experimenting  with  these  subparts  and  for 
designing  hybrid  solutions  capable  of  performing  under  a  variety  of 
temporal  and  other  constraints  on  behavior; 

•  it  should  clarify  the  identification  (design?)  of  tools  to  be  used  as  a  bridge 
between  specification  of  the  baseline  application  and  its  implementation 
and  facilitate  the  design  and  implementation  of  an  integrated  real-time 
MSDF/STA/RM  system. 

Other  specific  requirements  are  determined  by  the  purpose  of  the  C2  system  and  the 
nature  of  the  problem  spectrum  that  is  being  addressed  by  MSDF,  STA  and  RM  in  the  C2 
system.  The  C2  system,  which  includes  both  men  and  machines,  exists  to  aid  the 
Commanding  Officer  and  his  team  in  using  the  available  resources  to  achieve  the  mission. 
Generally  speaking,  the  C2  process  is  hierarchical.  In  particular,  this  means  that  mission 
objectives  are  progressively  decomposed  into  subordinate  objectives  until  a  level  is  reached 
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where  individual  resources  are  involved.  A  variety  of  levels  of  abstraction  in  the  C2 
problem  solving  process,  types  of  information  processing,  timing  constraints  on  this 
processing,  and  divisions  of  responsibility  between  men  and  machines  are  thereby 
involved.  The  problem  spectrum  is  identified  in  Fig.  18  and  the  portion  of  the  spectrum 
occupied  by  each  of  MSDF,  ST  A  and  RM  is  roughly  delineated.  However,  the  spectrum 
for  human  systems  integration  with  these  automated  processes  is  not  given  here  as  such 
important  issues  remain  to  be  more  clearly  defined. 
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FIGURE  18  -  MSDF/STA/RM  problem  spectrum 

In  view  of  these  considerations,  a  layered  software  architecture  appears  to  offer  an 
attractive  basis  on  which  to  build  a  suitable  integration  framework.  A  first  attempt  at 
specifying  this  software  architecture  at  a  high-level  is  given  in  Fig.  19.  Layering  provides 
an  effective  means  of  responding  to  the  requirements  described  above.  In  addition,  it 
promotes  the  clear  separation  of  design  issues  from  implementation  and  performance 
issues.  For  example,  no  assumption  is  made  in  Fig.  19  on  the  underlying  hardware  on 
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FIGURE  19  -  A  first  cut  at  a  layered  architecture  for  integration 
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which  the  various  layers  are  to  be  implemented  and,  in  fact,  several  distinct 
implementations  of  communication  mechanisms  may  also  be  needed  depending  on  the 
specific  implementation  that  is  adopted,  e.g.,  uniprocessor  or  multiprocessor.  Typically, 
lower  layers  in  the  architecture  will  operate  rapidly,  with  high  frequency  and  short  delays. 
The  layered  software  approach  is  therefore  conducive  to  the  development  of  a  variety  of 
layer-specific  run-time  executives  (RTEs),  depending  on  the  nature,  temporal 
characteristics  and  implementation  of  transformations  on  the  information  flows  in  a  layer, 
and  the  services  required  in  that  layer.  Depending  on  system  design,  the  functionality  of  an 
executive  may  be  provided  as  part  of  the  application  in  a  layer,  as  part  of  a  real-time  kernel, 
or  exist  as  a  separate  service  sub-layer.  These  are  design  choices  that  will  have  to  be  made. 

We  note  that  no  attempt  is  made  in  Fig.  19  to  align  the  databases  and  the  various 
HCI  components  in  accordance  with  the  layering  in  MSDF,  ST  A  and  RM  since  this 
requires  more  careful  study.  In  addition,  further  work  is  needed  to  describe  the  details  of 
each  of  the  MSDF/STA/RM  layers  shown  there.  These  and  other  issues  will  receive 
attention  in  the  second  document  (i.e.,  "Report  #2")  to  be  delivered  for  the  task.. 

So  far,  we  have  addressed  the  structure  of  the  integration  framework.  There 
remains,  however,  the  important  issue  of  the  design  methodology  for  achieving  this 
integration.  This  methodology  will  be  described  in  "Report  #2".  We  note,  however,  that  it 
will  be  founded  on  a  synthesis  of  many  different  views  of  the  integrated  real-time 
MSDF/STA/RM  system  which  are  needed  for  its  complete  specification.  To  conclude  this 
section,  we  present  five  views  that  will  need  to  be  accounted  for. 

1)  Combat  Environment:  The  combat  environment  includes  the  ship  and  its 
organic  and  non-organic  information  sources,  weapon  systems,  and  the 
targets,  both  friendly  and  hostile,  the  physical  environment,  and  the 
liveware.  (Note  that  in  Fig.  19  the  liveware  accesses  the 
MSDF/STA/RM  system  via  the  HCI  subsystem.)  This  view  requires  an 
accurate  description  and  analysis  of  the  behavior  of  the  environment, 
including  its  temporal  aspects. 

2)  Functional  Requirements:  This  describes  the  input-output  behavior  of 
the  various  system  components  in  each  layer,  as  well  as  their 
hierarchical  specification. 
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3)  System  Behaviour:  This  view  addresses  questions  of  when,  how  and 
why  things  happen  as  the  MSDF/STA/RM  system  reacts  and  changes 
state  over  time. 

4)  Performance  Evaluation:  The  performance  objectives  of 
MSDF/STA/RM  are  specified  here  and  a  plan  of  action  for  achieving 
them  is  prescribed.  This  plan  will  undoubtedly  be  concerned  with  issues 
of  assigning  tasks  (statically  or  dynamically)  to  the  hardware 
components  of  the  physical  ASCACT  testbed,  their  scheduling  and 
potential  migration  among  these  components  as  a  (time-dependent) 
function  of  system  load  and  time  criticality.  Achieving  this  may  require 
extensive  performance  profiling  using  high-performance  simulation- 
based  technologies  to  identify  performance  bottlenecks  and  system 
limitations,  and  to  evaluate  appropriate  tradeoff  mechanisms. 

5)  Hardware/Software:  This  view  describes  the  underlying  structure  of  the 
testbed,  including  its  processor  components  and  interconnects  and  the 
means  of  achieving  the  use  of  these  resources  via  OSs,  compilers  and 
high-level  communication  mechanisms. 
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5.0  THE  ASCACT  INTEGRATION  WORKING  GROUP 

This  chapter  discusses  the  ASCACT  Integration  Working  Group  (AIWG)  that  was 
established  by  DMSS  8  and  DREV  in  November  1994  to  fulfill  a  requirement  jointly 
identified  for  a  formal  information  exchange  mechanism  between  the  two  organizations 
about  R&D  issues  relevant  to  ASCACT.  The  mandate,  membership  and  operations  of  the 
group  are  briefly  presented  below. 

5.1  Mandate  of  the  Group 

The  main  purpose  of  the  AIWG  is  the  preparation  of  the  SOW  (based  on  the 
completion  of  the  requirements)  for  the  ASCACT  Integration  Phase  Project  Definition 
Study  (INTPDS)  leading  to  the  implementation  of  real-time  MSDF,  ST  A  and  RM  on  the 
ASCACT  integration  testbed.  The  AIWG  should  enable  an  information  transfer  to  occur 
between  the  main  DND  contributors  to  the  project.  The  group  utilizes  an  iterative  approach 
that  should  lead  to  a  sound  development  minimizing  the  risks  during  the  implementation 
phase.  The  purpose  of  the  AIWG  is  also  to  define  DREV's  involvement  within  the 
INTPDS  and  the  subsequent  implementation  phase. 

The  timeline  for  the  completion  of  the  INTPDS  SOW  has  been  established  as 
January  1996,  with  commencement  of  the  INTPDS  planned  for  late  March  1996.  The 
estimated  timeline  for  the  beginning  of  the  implementation  phase  is  January  1997. 

5.2  Membership 

The  AIWG  primarily  consists  of  members  from  DREV  and  DMSS  8  with 
representation,  as  required,  from  DSAM,  DMSS  6,  DREO  and  other  agencies  associated 
with  the  fields  of  MSDF,  STA,  RM  and  other  shipboard  CCIS  related  matters.  It  is  chaired 
by  LCdr  E.G.  McLean,  DMSS  8-8,  Project  Manager  (PM)  for  ASCACT.  The  current 
members  of  the  group  are: 

Dr.  £.  Bosse  DREV/DST  Section 

Mr.  R.  Carling  DREV/DST  Section 

Dr.  B.  Chalmers  DREV/DST  Section 

Mr.  J.-P.  Lachance  DMSS  8-8-2  (Project  Engineer  ASCACT) 

Cdr  D.  Parks  DSAM  2  (Project  Director  (PD)  ASCACT) 
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Mr.  J.  Roy  DREV/DST  Section 

Mr.  U.  Seltitz  DMSS  8-2 

DMSS  6  has  been  invited  to  participate  in  the  activities  of  the  group  (currently  with 
Mr.  A.  Beaulieu  as  their  representative)  to  provide  input  on  how  MSDF  is  to  be 
implemented  in  the  ASCACT  testbed. 

5.3  Operations 

Via  monthly  meetings,  as  illustrated  in  Fig.  20,  the  AIWG  must  resolve  the 
ASCACT  testbed  requirements.  More  precisely,  in  collaboration  with  DMSS  and  DSAM 
through  an  active  participation  in  the  AIWG,  DREV  will  identify,  capture,  analyze  and 
document  the  requirements  for  the  ASCACT  integration  testbed  in  terms  of  stimulator, 
measures  of  performance,  environment  modeling,  data  fusion,  situation  and  threat 
assessment,  resource  management,  processing  requirements,  etc.,  in  order  to  generate  a 
highly  flexible  testbed. 

The  end  result  will  be  a  foundation  for  the  generation  of  the  SOW  for  the  Project 
Definition  Study  (PDS)  for  the  integration  phase.  DREV  will  also  assist  DMSS-8  in  the 
establishment  of  this  SOW  and  in  the  evaluation  of  the  PDS  proposals. 
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DREV  /  DMCS  7  Meeting 

•  Discussion  of  MSDF/STA/RM  Technologies 
>  Decisions  on  Way  Ahead 

» Formation  of  the  "ASCACT  Integration  Working  Group" 


ASCACT  Integration  Working  Group  Meeting 
•  Finalize  ASCACT  Testbed  Requirements 

-  Performance  Metrics 

-  Closed-Loop  Stimulator 

-  Environment  Modeling 

-  MSDF/STA/RM  Application 

-  Methodology 

-  #  Sensors 

-  #  Contacts 

-  Raw  Data? 

-  Processor  Requirements 

-  Costs 

-  etc. 


Meet 

Once 

Monthly 


Generate  SOW  for 
Integration  Phase  PDS 


Integration  Phase 
Project  Definition  Study 


Generate  SOW  for 
Implementation  Phase 


Senior  Review  Board  (SRB) 
for  the  Implementation  Phase 


Implementation  Phase 


FIGURE  20  -  Operations  of  the  ASCACT  Integration  Working  Group  (AIWG) 
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6.0  CONCLUSION 

Through  an  active  participation  in  the  ASCACT  Integration  Working  Group 
(AIWG),  the  Data  Fusion  and  Resource  Management  (DFRM)  group  at  DREV  is  currently 
providing  consulting  services  in  support  of  the  preparation  for  the  Integration  Phase  of  the 
ASCACT  project.  Due  to  the  extent  of  DREV  resources  required  for  the  successful 
completion  of  the  ASCACT  testbed,  a  new  task  has  been  defined  to  provide  the  required 
support  for  the  project.  This  task  is  conducted  by  the  DFRM  group  with  DMSS  8  as  the 
sponsor. 

This  document  is  the  first  of  three  to  be  produced  by  DREV  as  deliverables  for  the 
task.  The  contents  of  this  document  respond  to  the  requirements  of  Activity  1  as  specified 
in  the  Task  Description  Sheet  (TDS).  In  that  respect,  the  R&D  work  conducted  at  DREV  in 
the  areas  of  MSDF,  ST  A  and  RM  that  can  potentially  be  used  in  the  ASCACT  testbed  was 
identified  and  described  and  the  level  of  effort  to  port  that  technology  to  ASCACT  was  also 
discussed.  The  baseline  information  necessary  to  get  a  working  knowledge  of  the  past, 
current  and  future  activities  relevant  to  the  project  was  provided.  Hence,  in  addition  to  the 
presentation  of  DREV's  R&D  work,  an  overview  of  the  ASCACT  project,  a  discussion  of 
the  context  in  which  the  project  is  conducted,  and  a  description  of  the  AIWG  mandate  and 
activities  were  also  provided  in  this  document. 

The  ASCACT  project  and  testbed  were  described  in  Chapter  2.0.  The  aim  of  the 
project,  along  with  a  description  of  its  main  phases,  and  the  DND  support  for  the  project 
were  given.  Some  information  about  the  context  in  which  the  ASCACT  activity  is 
conducted  was  also  given  in  this  chapter.  In  particular,  the  project  was  identified  as  a  major 
component  of  a  set  of  tools  and  activities  relevant  to  the  development  and/or  acquisition  of 
integrated  shipboard  C2  systems  for  the  CPF.  Given  the  broad  scope  of  the  issues  raised  in 
the  enhancement  activities  put  forward  for  the  CPF  CCIS,  it  has  been  quickly  recognized 
by  the  AIWG  that  no  single  tool  or  activity  will  be  sufficient  to  provide  DND  with  all  the 
required  answers.  The  R&D  environment  for  the  CPF  CCIS  must  rather  provide  a 
compatible  set  of  tools  and  testbeds  starting  with  the  DREV  testbeds  for  basic  proof-of- 
concept  research,  then  continuing  with  the  ASCACT  testbed  for  research  and  development, 
some  combination  of  ASCACT  and  a  shore-based  SHINPADS  bus  system  for  advanced 
development  and,  the  shipboard  system  for  user  feedback  and  trials.  Moreover,  the  R&D 
process  for  the  CPF  CCIS  will  undoubtedly  require  several  iterations  in  the  proposed 
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tools/activities  loop,  where  the  results  of  one  iteration  lead  to  refinements,  extensions  and 
improvements  in  the  next  iteration.  It  is  also  evident  that  progress  will  both  impact  and  be 
impacted  by  naval  requirements  (i.e.,  the  customer  must  be  kept  involved  during  this 
iterative  process)  and  that  this  interaction  may  subsequently  even  help  in  shaping  naval 
doctrine.  As  such,  this  will  require  work  both  inside  and  outside  the  immediate  scope  of  the 
ASCACT  project. 

The  integration  of  the  non-organic  information,  which  is  deemed  as  essential  to  the 
ASCACT  testbed,  was  also  discussed  in  Chapter  2.0.  The  ASCACT  project  (and 
equivalently  its  associated  integration  testbed)  has  been  conceived  to  address  data 
processing  R&D  issues  relevant  to  the  tactical  CCIS  of  CPFs.  Moreover,  the  emphasis  for 
the  first  baseline  application  to  be  implemented  and  investigated  with  the  ASCACT  testbed 
is  currently  given  to  the  management  of  the  organic  information  for  the  CPF  (i.e., 
MSDF/STA/RM  based  on  CPF  organic  resources).  However,  the  ASCACT  project  team 
also  considers  other  aspects  (e.g.,  the  integration  of  the  non-organic  information,  the 
strategic  issues)  associated  with  the  global  C2  architecture  put  forward  for  the  Forces.  For 
example,  R&D  for  the  shipboard  CCIS  must  take  into  account  the  issues  related  to  the 
various  CCISs  ashore.  In  terms  of  the  future  expansion  of  the  ASCACT  testbed,  the  hooks 
to  evolve  from  a  tactical  only  system  to  a  system  that  also  operates  on  strategic  information 
must  be  identified.  The  potential  input/output  requirements  for  the  MSDF/STA/RM  baseline 
application  running  on  the  testbed  must  be  identified.  In  that  respect,  two  major  activities 
that  are  closely  monitored  by  the  ASCACT  team  in  order  to  ensure  that  the  ASCACT 
testbed  will  remain  in  line  with  progress  made  during  the  CF  global  C2  architecture 
evolution  were  briefly  discussed.  These  are  the  management  of  organic  and  non-organic 
information  in  the  maritime  environment  and  the  national  level  command  and  surveillance 
activities. 

The  R&D  work  conducted  at  DREV  in  the  areas  of  MSDF,  STA  and  RM  was 
identified  and  briefly  described  in  Chapter  3.0.  The  mission  of  the  DFRM  research  group 
was  first  introduced,  along  with  various  definitions  (i.e.,  data  fusion,  etc.)  derived  and 
adopted  by  the  DFRM  group  to  establish  the  scope  of  its  work.  The  many  R&D  outcomes 
resulting  from  the  activities  of  the  group  were  then  summarized  and  discussed  for  each 
research  area  taken  individually,  followed  by  some  remarks  on  the  investigation  of  the 
MSDF/STA/RM  integration  issue.  The  discussion  of  these  R&D  results  also  included  some 
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references  to  current  work  (in  particular,  a  study  for  the  definition  of  a  conceptual 
framework  for  shipboard  CCISs  and  a  collaborative  project  with  the  industry). 

Chapter  3.0  only  summarily  discussed  the  level  of  effort  required  to  port  the 
MSDF/STA/RM  technology  R&D  results  from  DREV's  work  to  ASCACT.  A  significant 
amount  of  work  still  remains  to  be  done  on  identifying  which  areas  of  DREV's  available 
results  and  proposed  work  should  be  implemented  and  further  investigated  within  the  initial 
version  of  the  ASCACT  testbed.  Recommendations  must  be  made  on  which  areas  best 
meet  ASCACT  requirements  for  implementation,  while  carefully  considering  the  risk  of 
advancing  with  undeveloped  theories  and  applications.  The  areas  of  study  should  possess 
high  potential  for  success  (i.e.,  follow  a  medium  risk  approach)  and  be  able  to  be  ported  to 
a  shipboard  application  for  operator  assessment  (although  the  timeline  for  this  port  remains 
to  be  defined).  As  much  as  possible  ideally,  consideration  should  also  be  placed  on 
international  work  which  has  been  accomplished  in  these  fields  to  ensure  duplication  of 
effort  is  minimized  (i.e.,  do  other  countries  have  algorithms,  development  models  which 
could  be  used?).  These  considerations  mentioned  above  fall  beyond  the  scope  of  this 
document  and  will  be  addressed  in  a  subsequent  document  to  be  delivered  for  the  task. 

The  main  motivations  behind  a  real-time,  integrated  MSDF/STA/RM 
implementation  in  the  ASCACT  testbed  tool  were  identified  and  discussed  in  Chapter  4.0. 
The  specific  factors  that  motivate  DREV's  use  of  this  tool  were  first  discussed  with  respect 
to  each  of  the  main  areas  of  research  taken  individually  (i.e.,  MSDF,  STA  and  RM).  Then 
the  integration  aspect  was  addressed.  In  parallel  with  continuing  efforts  within  the  DFRM 
group  to  effect  refinements  and  improvements  in  the  individual  MSDF,  STA  and  RM 
processes,  an  important  new  research  focus  has  emerged  recently,  aimed  at  addressing  the 
integration  problem  in  a  top-down  manner  and  at  evaluating  its  potential  solutions.  In  that 
respect,  a  key  goal  is  the  development  of  a  methodology  for  achieving  this  integration, 
which,  ideally,  is  independent  of  the  particular  weapon  and  sensor  technologies  involved 
and  which  allows  for  the  incorporation  of  inevitable  advances  in  computer  hardware  and 
software  technologies. 

An  essential  step  in  establishing  the  methodology  mentioned  above  is  the 
development  of  the  ASCACT  testbed  as  a  versatile  testbed  that  can  serve  as  a  tool  for 
extensive  exploratory  and  empirical  analyses  and  evaluation  of  theoretical  concepts  that  are 
fundamentally  important  to  achieving  the  MSDF/STA/RM  integration.  This  testbed  will 
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therefore  have  a  major  role  to  play  in  studying  the  problems  associated  with 
MSDF/STA/RM  integration.  In  addition,  it  will  provide  a  serious  basis  for  evaluating  our 
past  R&D  progress  and  for  making  important  tradeoff  decisions  related  to  our  future  efforts 
in  MSDF,  ST  A  and  RM.  For  example,  we  shall  be  in  a  position  to  provide  well-founded 
answers  to  fundamental  questions  like:  what  are  the  individual  and  collective  perfoimances 
of  these  processes  that  can  be  realistically  automated  in  real-time?;  how  do  we  know  that 
our  work  on  theoretical  concepts  is  leading  to  realizable  performance  improvements  on 
board  the  ship  and  what  is  their  impact  (both  absolute  and  relative)  on  improving  mission 
success?;  in  short,  how  do  we  know  we  are  making  progress,  and  at  what  cost?  While  this 
is  clearly  an  ambitious  path  to  follow,  it  is  an  essential  and  much  needed  one. 

The  selection  of  an  appropriate  MSDF/STA/RM  integration  framework  as  a  basis 
for  subsequently  defining  a  baseline  application  in  the  ASCACT  testbed  is  an  important 
issue  still  to  be  resolved.  The  rationale  for  the  selection  of  this  framework  was  presented  in 
Chapter  4.0,  along  with  a  first  high-level  cut  at  its  design.  Further  details  and  refinements 
of  this  framework  will  be  given  in  the  second  document  to  be  delivered  for  the  task. 

The  AIWG  established  by  DMSS  8  and  DREV  to  fulfill  a  requirement  jointly 
identified  for  a  formal  information  exchange  mechanism  between  the  two  organizations 
about  R&D  issues  relevant  to  ASCACT  was  finally  discussed  in  Chapter  5.0.  The 
mandate,  membership  and  operations  of  the  group  were  briefly  presented. 
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